Live data from Hacker News

There’s No Such Thing as Clean Code

steveonstuff.com

81–90 of 395 posts

Re: There’s No Such Thing as Clean Code

#81

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...

Hmm...polymorphism is almost invariably simpler than if/else or switch/case, so not seeing the contradiction.

I've seen this happening a lot:

- you have the same if-then-else in 3 places in code with 3 different effects

- you refactor it to polimorphism (Enum with a few overloaded methods works well in java)

- now one of these places need additional condition so you make it a little more complex

- year passes

- you have eldritch abomination of OOP instead of 3 if-then-elses with slightly different conditions because at no point someone was brave enough to refactor back into if-then-elses as the special cases piled up

Re: There’s No Such Thing as Clean Code

#82

> There’s no such thing as clean code. > ‘Clean’ isn’t a measure of anything useful. Code can’t be clean simply because ‘clean’ doesn’t describe anything about code. Ehhhh. There is absolutely such a thing as clean code. But yes; what there isn't a way to measure code cleanliness (although there's lots of surrogate measures; see every linter) which means there's also no way to render it into a dogma... ...and to (per…

>Ehhhh. There is absolutely such a thing as clean code. But yes; what there isn't a way to measure code cleanliness

Well, in several epistemologies the second admission means there's no such a thing (or that, it might as well not exist).

Re: There’s No Such Thing as Clean Code

#83
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…

> 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.

Re: There’s No Such Thing as Clean Code

#84
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…

> 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 can replace multiple if/else/switch/case with a single one.

It has benefits, if you do not apply it dogmatically everywhere

Re: There’s No Such Thing as Clean Code

#85
I really like "Clean Code", it's because other people/programmers could easily navigate the code, while not knowing everything that happens in the code.

But in some rare cases, that's not what you want. Some functionality may need to require to know exactly what it does, because everything affects each other.

And then i create a "class of mud" that does everything since everything is connected, where the naming conventions of Clean Code still applies.

In my case, it was proxying json request bodies from an api to a 3rd party internal secure network where I had 1 dedicated pc running, where it could fulfill the request over a message broker (Service Bus in this case, to the internet network), execute the request that should work in the internal network and then send the response back through the message broker and give a response in the original API.

That class was shared (and exactly the same) for the server and client. Only one was implementing it as a subscriber and the other one as a listener.

The class was also commented à la SQLite, but no other classes in that code needed any comments - clean code wise.

( fyi, it was an internal secure api, that needed a 3rd part y ( our clients ) network)

Re: There’s No Such Thing as Clean Code

#87

> There’s no such thing as clean code. > ‘Clean’ isn’t a measure of anything useful. Code can’t be clean simply because ‘clean’ doesn’t describe anything about code. Ehhhh. There is absolutely such a thing as clean code. But yes; what there isn't a way to measure code cleanliness (although there's lots of surrogate measures; see every linter) which means there's also no way to render it into a dogma... ...and to (per…

> No. That's the trap of Goodhart's Law. You need something outside of your metrics so that your metrics don't become your target.

How can you make a metric out of "we aren't really sure what the direction of change for this feature is going to be, so it should be easy to refactor"? and why would that metric be any more likely to fall victim to Goodhart's Law than "the code should be clean"?

Re: There’s No Such Thing as Clean Code

#88
The title is click-bait but the conclusion makes sense. It's just unfortunate that most people have such different ideas about what 'clean code' means. I guess people will ascribe that label to any code which they produce. Everyone (regardless of actual competence) wants to think of themselves as a good developer who writes clean code.

My own definition of 'clean code' means maintainable (anticipates some broad future requirements) and avoids inventing unnecessary abstractions or adding layers of indirection (which just adds complexity and gives other people more work to familiarize themselves with the code).

Re: There’s No Such Thing as Clean Code

#90
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.

Post reply on HN