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

111–120 of 395 posts

Re: There’s No Such Thing as Clean Code

#111

Post by jmchuster »

Code needs to be able to do what you need it to do. So anything that makes that job harder, could be considered not "clean". That might include...

- code that is inconsistent. This causes additional overhead and mental burden when thinking about code. Trying to find what's truly logically different is hard when there are additional differences that shouldn't be there in the first place.

- incomplete code. This might be a concept that was done halfway and then stopped. So there's additional mental burden of, this is what is meant to be done, but it hasn't been done in these places yet, so understand the code is being pulled in two different directions, and also keep that original plan in mind so that you converge those past plans with your current line of work.

- buggy code. Code that looks like it should work but then doesn't causes issues when you can't tell if an error is in something new you're developing or something that existed already.

- code that is hard to accommodate the new change. This one finally gets a bit fuzzier, as the more infinitely flexible you make it, the worse it'll be at matching the task at hand. If you are better at predicting the future, you might be able to set yourself up so that it's slightly easier for anticipated future development, with minimal impact to what you currently need it to accomplish. So this might not be an issue of "unclean" code but just the reality of changing businesses. Of course, it is also possible to just make design decisions here that are objectively bad no matter what the future plans are.

You'll kind of find what is considered "clean" depending on your work place, what your engineering culture is like, what tradeoffs and priorities you have as an org. Basically, what is it that makes my job harder? That's what you then need to "clean" up. e.g. some orgs might say that lack of unit tests makes their job harder, and others might say it makes little difference, so then lack of testing might or might be a "clean" point depending on your org.

Re: There’s No Such Thing as Clean Code

#112

Post by lmm »

bsza wrote: post #104
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.

Look more carefully, there's no contradiction. Splitting a method into several independent methods doesn't mean you repeat yourself.

Re: There’s No Such Thing as Clean Code

#113

Post by MauranKilom »

jmchuster wrote: post #111

Code needs to be able to do what you need it to do. So anything that makes that job harder, could be considered not "clean". That might include... - code that is inconsistent. This causes additional overhead and mental burden when thinking about code. Trying to find what's truly logically different is hard when there are additional differences that shouldn't be there in the first place. - incomplete code. This might…

> Code needs to be able to do what you need it to do. So anything that makes that job harder, could be considered not "clean".

That reinforces the author's point that "clean" is synonymous for "good", without any added precision. Try interchanging the two in your comment - it reads exactly the same.

Re: There’s No Such Thing as Clean Code

#114

Post by MauranKilom »

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

> 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

Any time a class has invariants to maintain, you probably need private. That could be infrequent in your experience, but overall, invariants are a cornerstone of abstractions.

Re: There’s No Such Thing as Clean Code

#115

Post by dtech »

loriverkutya wrote: post #91
tikhonj wrote: post #27

Earlier quoted context omitted.

Writing is a great metaphor: there aren't any hard-and-fast rules and there's certainly a subjective quality to it... but also, some writing is clearly better and some writing is clearly worse. Maybe there is no such thing as "good" writing because writing can be "good" in different ways or because we can never fully define what "good" means, but that doesn't mean that all writing is equal or that "everything is a tr…

Writing would be a great metaphore only if you write the code alone and when you declared it finished, you never need to come back and add new things/remove old things or fix bugs in it.

I don't see how that invalidates the metaphor. For any version of code you can evaluate clean-ness. Writing is also not immutable, professional authors make hundreds of versions before publishing.

Of course books get 1 major release. So while ability to maintain and change is much more important in software, that is by far not the only factor for clean-ness, and I'd say hardly the most important.

Re: There’s No Such Thing as Clean Code

#116

Post by karatinversion »

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

> 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 restrict access to its state so it can maintain invariants? E.g. the simplest classes I can think of, like a vector that consists of a pointer to a buffer, a length and a capacity, wouldn't want to provide a setter for the buffer, or allow callers to set it to a random value?

Re: There’s No Such Thing as Clean Code

#117

Post by GordonS »

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

...for trivial cases. For more complex, real-world scenarios, these kind of rules need to be applied sparingly, and where needed. Otherwise you get things like too much abstraction and several layers of inheritance, making it difficult to figure out what anything actually does - the opposite of nice to read

Uncle Bob et al have some good guidance, but cargo-culting them led to long-lasting, negative effects on some communities, such as Java and C# developers.

Re: There’s No Such Thing as Clean Code

#118

Post by bsza »

lmm wrote: post #112
bsza wrote: post #104

Earlier quoted context omitted.

> Don't use flag arguments. Split method into several independent methods that can be called from the client without the flag. vs > Needless Repetition.

Look more carefully, there's no contradiction. Splitting a method into several independent methods doesn't mean you repeat yourself.

The flag check could be deep within a loop, how would you split it then without repeating the whole method?

Re: There’s No Such Thing as Clean Code

#120

Post by rhdunn »

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

I read that as "one operation per test". Specifically, both:

    assertEqual(complex(1, 2) + complex(3, 5),
                complex(4, 7));
and:

    auto c = complex(1, 2) + complex(3, 5);
    assertEqual(c.re(), 4);
    assertEqual(c.im(), 7);
would both satisfy that requirement, but:

    assertEqual(complex(1, 2) + complex(3, 5),
                complex(4, 7));
    assertEqual(complex(1, 2) + complex(-3, -5),
                complex(-2, -2));
would not. -- In that case, Clean Code is advocating having something like a "test adding positive complex numbers" and "test adding a positive complex number to a negative one". This makes it clear in the test failure report which of the operations and conditions has failed.
Post reply on HN