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

101–110 of 395 posts

Re: There’s No Such Thing as Clean Code

#101

Post by bryanrasmussen »

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.

In Java (or Java like languages [C#]), which is the language they were really written for. There are many languages for which the precepts of Clean Code are not that great a fit.

Also - It's probably time to stop recommending Clean Code - https://qntm.org/clean

Re: There’s No Such Thing as Clean Code

#102

Post by viceroyalbean »

hyperman1 wrote: post #93
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...

I see polymorphism vs if/... more as a tradeoff. For example: Suppose the program has to make a choice. When the choice exists only in 1 place, use an if/switch. When the choice exists in multiple places, polymorphism centralizes it and quickly becomes the simple option. For example, a change in law required us to make a choice based on a date: If (thing.someBusinessDate after a while, a few edge cases sprang up, and…

I agree with you, especially in instances where that decision logic is unrelated to the data that is actually being used. In your example you'd have to pass "thing" everywhere just for that if-statement, but it might not be used for anything else.

That said, I think "simple" if/else or switches are much more common than the complex cases that fit polymorphism, so it seems a bit off to have it as a general rule to prefer polymorphism.

Re: There’s No Such Thing as Clean Code

#103

Post by _0w8t »

onion2k wrote: post #83
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...

Polymorphism is more complex than a switch/case in a single instance . Across a large codebase using polymorphism instead of hundreds of different switch/cases is simpler, especially when you need to change something. Encapsulating what a class should do within the class instead of in an external code block is much simpler when you're working on something big.

Polymorphism is a switch, but it is the switch over object kind, not action. In fact if there are only few subclasses compilers for some languages where a global analysis is possible implement polymorphic calls as switches over the object tag.

And notice how if one needs to add a new action, all objects are required to implement it. In typical OOP languages that touches many files even if the action is used only once.

So polymorphism works nicely if there are only few actions but many different objects, like in a typical GUI. But in cases of few objects and many actions, for example, doing a lot of different queries over few data sets it leads to a lot of boilerplate. Switch over actions will lead to less code.

Re: There’s No Such Thing as Clean Code

#104

Post by bsza »

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 use flag arguments. Split method into several independent methods that can be called from the client without the flag.

vs

> Needless Repetition.

Re: There’s No Such Thing as Clean Code

#105

Post by throwawayffffas »

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…

> that you can confidently change.

There is no secret to this, it's merely tests, no matter how clean my code is I would not feel confident unless I have tested my changes, whether manually or automatically and manually quickly becomes intractable.

There is the option of formal verification, but I have found the tooling to be disagreeable with me.

Re: There’s No Such Thing as Clean Code

#106

Post by karottenreibe »

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…

In my experience you absolutely SHOULD document every request and removal in e.g. an issue tracker. It's very valuable information.

And commented out code gets stale so quickly. Much better to check out an old version where it still worked than uncommenting a bunch of lines that now have compile errors and have become incomprehensible. Happens so easily, e.g. after some variable renames.

Re: There’s No Such Thing as Clean Code

#107

Post by Hermitian909 »

moonchrome wrote: post #90
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 remember going over unclebob github a while back and this wasn't the impression I got. The parts I read seemed like obtuse code that added pointless abstraction for the sake of following some convention.

This is my experience as well. It takes a long time to grok what the program does and how it does it because of all the layers of indirection, even when the program is fairly simple. While this style might make small changes easy if you understand the code, the inertia to larger changes because of the layers of indirection is immense.

Re: There’s No Such Thing as Clean Code

#108

Post by rootlocus »

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"…

> One assert per test

Was meant to make a failed test instantly communicate what's wrong with the unit under test. As frameworks evolve and our practices around them change, it's absolutely fine to come up with new rules.

All of uncle Bobs rules come with pages of explanations of what problems they solve. If you don't have those problems, you may not need those solutions. The book is more about the spirit of the law than the letter.

Re: There’s No Such Thing as Clean Code

#109

Post by otikik »

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…

On the internet I have very rarely encountered "Clean Code" as code following explicitly the rules listed by Bob Martin in his books. People use it like the OP says - "code that feels good to me in the moment, without being able to explain why".

I believe that's because the term Clean can be intuitively defined in opposition of quick and dirty : "I have spent a lot time on it. So it isn't quick and dirty. It's clean."

Re: There’s No Such Thing as Clean Code

#110

Post by dtech »

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…

Seems garbage advice to me. Now you've polluted your production code, likely forever. I don't see a situation where using an issue tracker + good commits - e.g. 1 commit for the 1 PR linked to the ticket that removes the feature - won't result in a superior situation from a maintenance and traceability perspective.
Post reply on HN