Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Clean Code

overreacted.io

Post reply on HN
Print view View original

351–360 of 599 posts

Re: Goodbye, Clean Code

#351

Post by Mirioron »

lonelappde wrote: post #229
Mirioron wrote: post #198

Earlier quoted context omitted.

I wonder if we could have IDE features that will make #2 less likely. Eg marking some lines of code that they're similar to lines of code elsewhere. And if you then change it in one place the IDE will remind you about the others.

Relying on your IDE to maintain program semantics is terrible. IDE should help you write good code that you commit, not be a crutch for writing bad code.

People in the thread are arguing that it's not necessarily bad code though. Also, the point of the IDE would be to help you just not forget to change it.

Re: Goodbye, Clean Code

#352

Post by grogenaut »

DonHopkins wrote: post #323
grogenaut wrote: post #310

Earlier quoted context omitted.

Old boss of mine had a great line: "two points always make a line, but three usually makes a triangle"

Your boss made a good point. My boss also made the exact same good point. But between those two same good points, there isn't a great line. ;)

We had introspective bosses?

Re: Goodbye, Clean Code

#353

Post by pvorb »

lonelappde wrote: post #212
chubot wrote: post #192

Earlier quoted context omitted.

That’s why I make the test fail before writing the code. If the code is already written, then I break it in the minimal way to test the test, and then fix it.

That's a test for your test, so why only run it once transiently instead of running every time? "Mutant" testing helps with this. It's basically fuzzing your test code to make sure that every line is meaningful.

And how do you do this in practice? I am struggling to think of a good way to keep the production code that fails the test and the production code that doesn't fail the test together. I might have my test check out an old version of the production code, compile it and test against that. But that is hard to get right.

Re: Goodbye, Clean Code

#355

Post by _ph_ »

alireza94 wrote: post #314
bjourne wrote: post #274

> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagr…

> I also think that a salaried engineer who thinks that a piece of code he or she (but almost always he) wrote is "his" or "hers" is totally wrong This. If some developer get offended when there is some issue in their code or the way it got implemented either they are not mature enough or there is a cultural issue in the team.

The point is, code "ownership" shouldn't be understood as a term of property - of course it isn't the property of the programmer but the company - but in terms of responsibility. This might be different in very large teams, but usually, once you write a piece of code, you are the the prime responsible person for maintaining it. And as long as this is the case, I would expect to be involved in any significant change to the code. Of course I am fine with changes, which also transfer the responsibility :)

Re: Goodbye, Clean Code

#357

Post by JBSay »

I find this problem to be overblown. I've met dozens of dirty coders who happily copy-paste code without a single thought for maintainability and their colleagues. I've yet to meet a single clean code zealot.

It's impossible to tell from this example (because no actual code is included) whether refactoring the code was a bad idea or whether it was this specific implementation which was wrong. Clearly the math should sit in a geometry/linear algebra libraries and nowhere near the presentation layers.

Re: Goodbye, Clean Code

#358

Post by kuon »

If you really want to remove duplication, try the other way first, like this:

where there is

// 10 repetitive lines of math

write a few helper functions, like

// 3 repetitive lines of math calling my helper functions

I don't known what math was in this case, but removing duplication should preferably handled in this direction to avoid introducing more abstraction and in this case keep a full separation of concerns.

Re: Goodbye, Clean Code

#359

Post by hyko »

You are not saying goodbye to clean code: you are embracing it!

“Clean code” is a semantically overloaded term, so discussion about it is inevitably mired in confusion. Every brain that first hears the phrase “clean code” will construct some plausible placeholder definition, and the most readily available one by analogy is “less source code”.

You can easily try and apply principles such as SOLID and then go on to produce an unmaintainable web of nonsense, because they are meant to be facets of a unified organising principle and not a bag of tricks for local optimisation towards the state of “clean code”. I’ve experienced that firsthand.

“Clean code” is great marketing, but I almost wish Robert Martin had called his theories “Martin Code” so there was no doubt what is under discussion.

Re: Goodbye, Clean Code

#360

Post by blub »

kortilla wrote: post #333
jt2190 wrote: post #255

Earlier quoted context omitted.

> There's no way to codify concrete requirements for handling every possible way code can be improved. If the change can’t be codified, then it calls into question why the change needs to happen at all. Assuming that there is some improvement that can be justified, then explain it to the team, and have the team start reviewing for it. By not going through the process of explaining the improvement to the team, it sign…

If you don’t trust someone to change your code to make small improvements, it sounds like you have a trust problem, not the other way around. Working on a software project as a large team is like growing a garden, not building a house. Just because someone planted a hedge doesn’t mean it can’t be improved by pruning it.

Trust would allow that the code is modified in the first place, but then a code review needs to happen anyway to ensure that at least one more person is aware of the change and as a sanity check that the change makes sense.
Post reply on HN