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

There’s No Such Thing as Clean Code

steveonstuff.com

Post reply on HN
Print view View original

121–130 of 395 posts

Re: There’s No Such Thing as Clean Code

#121

Post by Toine »

yakubin wrote: post #96
onion2k wrote: post #59

The Uncle Bob Martin definition of "clean code" from his book "Clean Code: A Handbook of Agile Software Craftsmanship" is a set of rules that absolutely are not at odds with one another. If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. There's a decent summary here - https://gist.github.com/wojteklu/73c6914cc446146b…

> If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. I found that a lot of those guidelines lead to the exact opposite. Examples: - Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files) - Use dependency injection (same as above) - Hide internal structure (that "private"…

These are minor inconveniences relative to the massive benefits all these techniques bring to your codebase. "Go to implementation" shortcut is a thing and solves the first 2.

"One assert per test" -> just test one "concept" per test, not literarily 1 assert statement per test. IE :

  assert(loc.x == 10.3)
  assert(loc.y == 10.4)
  assert(loc.z == 10.5)
is absolutely fine (even you could do it in 1 assert).

Re: There’s No Such Thing as Clean Code

#122

Post by YEwSdObPQT »

yakubin wrote: post #96
onion2k wrote: post #59

The Uncle Bob Martin definition of "clean code" from his book "Clean Code: A Handbook of Agile Software Craftsmanship" is a set of rules that absolutely are not at odds with one another. If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. There's a decent summary here - https://gist.github.com/wojteklu/73c6914cc446146b…

> If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. I found that a lot of those guidelines lead to the exact opposite. Examples: - Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files) - Use dependency injection (same as above) - Hide internal structure (that "private"…

In simple cases many of the suggestions in the clean code book make things more complicated.

However when you get to larger programs big if ... else blocks become painful. Not having a DI mechanism becomes painful. Encapsulation becomes important because you will find other parts of the program modifying something when it really shouldn't be.

I used a moan about these things until they were taken away and then I really missed them.

Re: There’s No Such Thing as Clean Code

#123

Post by jseban »

yakubin wrote: post #96
onion2k wrote: post #59

The Uncle Bob Martin definition of "clean code" from his book "Clean Code: A Handbook of Agile Software Craftsmanship" is a set of rules that absolutely are not at odds with one another. If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. There's a decent summary here - https://gist.github.com/wojteklu/73c6914cc446146b…

> If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. I found that a lot of those guidelines lead to the exact opposite. Examples: - Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files) - Use dependency injection (same as above) - Hide internal structure (that "private"…

I agree, these rules make the code extremely verbose and over abstracted and scattered. The resulting code base will be several times the size of a straight forward solution, and this has a very big negative impact on maintainability.

Even if you use many files and only put a tiny amount of logic in each of them, you still need to have an understanding of the overall system and how things work together, and scattering things in more places, each with multiple wrappings, just makes that even harder.

Re: There’s No Such Thing as Clean Code

#124

Post by cjfd »

dt3ft wrote: post #92
onion2k wrote: post #59

The Uncle Bob Martin definition of "clean code" from his book "Clean Code: A Handbook of Agile Software Craftsmanship" is a set of rules that absolutely are not at odds with one another. If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. There's a decent summary here - https://gist.github.com/wojteklu/73c6914cc446146b…

> Don't comment out code, just remove I hate commented out code, but this doesn't work in every situation. While working on a clinical information system, we had frequent "please bring it back" requests that came a few months after things were removed (also by request). Relying on source control is nice, but unless you document every feature/removal or use very extensive commit messages, finding the code that was rem…

Yes, sometimes (not often) commented out code can be defended. The point of adding why it is commented out is very well taken. Then you can remove it if the reason for it still being there is not longer applicable. And commented out code tends to go stale quite quickly so if it really is not needed anymore it should be removed.

But I do wonder, if the better option would not have been to make the behavior that you commented out optional. Sometimes one can know beforehand whether a request is actually what people are going to want in the end. Once I wrote variant 1 of a certain feature. This was deemed not good and variant 2 was written. This was also not what people wanted so variant 3 was written. By then I got the inkling that also variant 3 would not be there to stay so I made it an option whether 2 or 3 was in effect. In the end, the final functionality was mostly a lot like variant 1 so the option turned out not be useful but maybe sometimes such optional behavior can sometimes be the best way....

Re: There’s No Such Thing as Clean Code

#125

Post by mcv »

beebmam wrote: post #71
raverbashing wrote: post #68

Earlier quoted context omitted.

> is a set of rules that absolutely are not at odds with one another Yes, if you take them as general guidelines, not dogmatic rules with variable interpretations The latter is exactly what his fans do > 2 .Keep it simple stupid > 2. Prefer polymorphism to if/else or switch/case. No, not at odds with one another...

Yeah, polymorphism is in no way simple in lots of languages/frameworks. It's actually quite complex in many common languages/frameworks. This is absolutely contradictory in my opinion, but I welcome disagreement :)

And then there's a language like Scala where switch/case is so naturally integrated that it actually becomes the cleaner solution and you basically have to use it.

Whatever approach is clean or not can vary wildly by language. Or framework.

I do like clean code, but I think the article has a point: it's a very vague concept.

Re: There’s No Such Thing as Clean Code

#126

Post by _hao »

rootlocus wrote: post #97
_hao wrote: post #80

There's a good take on this by Casey Muratori - https://www.youtube.com/watch?v=7YpFGkG-u1w And I agree with him. Things like SOLID and "Clean Code" really are just buzzwords nowadays that don't mean anything.

Casey lives in a bubble of his own, where he's the sole developer of every project he starts and he gets to make all the rules for himself. He doesn't really have customers, stakeholders, deadlines, he doesn't work on distributed enterprise software, etc. He makes indie tools and games. I really appreciate his push for simple and efficient, but in reality, the industry has spawned hundred of thousand of software deve…

> Casey lives in a bubble of his own, where he's the sole developer of every project he starts and he gets to make all the rules for himself. He doesn't really have customers, stakeholders, deadlines, he doesn't work on distributed enterprise software, etc. He makes indie tools and games.

Perhaps. I don't agree with everything he says all the time, however, from my own experience on working on distributed enterprise software I can say that following patterns blindly is an actual problem that impedes a good working solution designed for the specific problem(s) a lot of the time. Devs are pushed by DM's and PO's to have a working product ASAP and what might be a good idea for MVP prototype ends up being a burden down the line because now the entire system is built on top of that decision made in a moment in time without serious thought. Then some time passes and the whole thing crashes down. Then a rewrite happens in the exact same way and the wheel keeps on spinning.

My 0.02c are that I think we should build things more sustainably and expect software to work longer. We should hold ourselves to a higher standard.

Re: There’s No Such Thing as Clean Code

#127

Post by rob74 »

antris wrote: post #5

Coding is a highly subjective and creative endeavor. "Clean code" is akin to "well written" for writers. Sure, you can analyze and even be able to define some good practices, but because we are always creating something new that has never done before, and the field is infinitely complex, no rules can be set in stone and applied across everything. In my opinion there's nothing wrong with calling code clean, we don't h…

> There's just too many things to consider and viewpoints to take, we'd be trapped in analysis paralysis forever, as you can continue it to no end. There's never a point where the analysis will be "done".

I agree with you there - but this makes it even more bizarre that there are now tools (e.g. SonarQube) trying to automate this analysis. Of course, linters are a undeniably useful, but stuffing arbitrary rules into a tool which then gives grades to your code based on a strict interpretation of those rules is a bridge too far. I mean, can you really take software that uses terms like "blocker code smell" seriously?!

Re: There’s No Such Thing as Clean Code

#128

Post by klabb3 »

ahmaman wrote: post #29

Clean code is code that does what you expect it to do without many surprises. It is simple, not clever. Effortless to follow. Each part handles one idea at a time, at the same abstraction level. Doesn't force you to mentally juggle many balls at the same time. The code often tells you a story, it communicates how the programmer (author) described the problem, the solutions and the trade-offs. Very similar to writing.…

Agree with everything.

> Doesn't force you to mentally juggle many balls at the same time.

Coincidentally, this is how I define complexity colloquially for my own purposes. It is extremely general, stupidly practical, and literally rooted in brain chemistry.

Applying this to programming is still a delicate art, since it depends on what the reader of the code wants to do. Most people focus on clean modules (e.g. a 100 LOC unit testable data structure), but that's only helpful when the next person wants to modify or replace a single module, which is generally the easy part. Most times when I'm groking a new code base is spent understanding data flow across a complex hierarchy of modules – usually, the dumber and flatter, the easier this task becomes.

Re: There’s No Such Thing as Clean Code

#129

Post by tjajab »

karatinversion wrote: post #116
yakubin wrote: post #96

Earlier quoted context omitted.

> If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. I found that a lot of those guidelines lead to the exact opposite. Examples: - Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files) - Use dependency injection (same as above) - Hide internal structure (that "private"…

> Hide internal structure (that "private" is the default in C++, Java and Rust just adds to boilerplate; the default case is that you want everything public (unless you like writing trivial getters and setters just for the fun of it); legitimate uses of "private" exist, but are rare) This is such a strange POV to me. There are cases where your classes are just data records, but any object with logic surely wants to r…

I guess that for a lot of people it is the case where you have a class with mutable state that is the anomaly.

Re: There’s No Such Thing as Clean Code

#130

Post by galaxyLogic »

"Clean code" means about the same as "well-written code". Both have meaning. But the issue is that of course everybody and their uncle can agree that "clean" is "good".

The question is when somebody claims to have clean code, is it really? Why do you say it is clean? Does everybody agree it is "good code"?

It's much the same with "agile". Of course agile is good. Everybody can agree on that. But are people who claim to be agile really agile?

88% of drivers believe they are "above average". My guess would be that the same is true of programmers. Most of them are better than the average. :-)

https://www.adam-campbell.com/post/most-drivers-are-better-t...

Post reply on HN