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

91–100 of 395 posts

Re: There’s No Such Thing as Clean Code

#91

Post by loriverkutya »

tikhonj wrote: post #27
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…

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.

Re: There’s No Such Thing as Clean Code

#92

Post by dt3ft »

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 removed (especially if it was spread over several classes) is easier if you just comment it out and write why it was commented out.

The important part here is to add why something was commented out.

Re: There’s No Such Thing as Clean Code

#93

Post by hyperman1 »

raverbashing wrote: post #68
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…

> 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 we got variants of this code hiding in multiple corners. Then the law changed again with a new cutoff date. So we adapted to polymorphism:

  interface TheWay{ edgecase1(); edgecase2();...}    
  class TheOldWay implements TheWay{...}
  class TheNewWay implements TheWay{...}
  class TheNewNewWay implements TheWay{...}
  TheWay wayDetector(thing){/* all the ifs here */}
Unfortunately, adding just one more 'if' was always the cheapest choice. The refactoring was nevertheless clearly a better choice: it enabled us to point out more forgotten edge cases, avoiding costly mistakes.

Re: There’s No Such Thing as Clean Code

#95

Post by hbbio »

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…

Most items are great but I was unsure about "one assert per test" until I read the comment below:

>

Re: There’s No Such Thing as Clean Code

#96

Post by yakubin »

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

- One assert per test (I guess I need to throw my property-based tests out the window)

Re: There’s No Such Thing as Clean Code

#97

Post by rootlocus »

_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 developers these last decades, and collectively we've simulated every possible way of building software. The simple reality is, teams who followed well established patterns and good practices have had more success.

Re: There’s No Such Thing as Clean Code

#98

Post by tester34 »

Good/Clean code is context dependent

kernel's code is terrible mess by java/c# web app standards (dependency injection, interfaces, mockability, testability, etc)

Even C#'s compiler code written in C# is below architect's dream web app code base full of DDD, various patterns, CQRS, Event Sourcing yada yada

Re: There’s No Such Thing as Clean Code

#99

Post by rootlocus »

usrbinbash wrote: post #45

The fact that everyone can come up with his own definition of what "clean" is supposed to mean regarding code, tells us something very important about it: It has no intrinsic, defined meaning in the context of code. Saying code is "clean" is like saying food is "tasty"...its a personal opinion, not a defined term.

And yet we all agree, spoiled food tastes terrible.

Re: There’s No Such Thing as Clean Code

#100

Post by bobcostas55 »

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 an unreadable spaghetti made out of thousands of two-line functions.
Post reply on HN