Live data from Hacker News

Goodbye, Clean Code (2020)

overreacted.io

221–224 of 224 posts

Re: Goodbye, Clean Code (2020)

#221
post #196

Earlier quoted context omitted.

Looks to me like you dodged a bullet.

Yes, but it is hard to find teams who are not into abstracting for abstracting sake.

It is a good way to sort out prospects, then.

I know people who actually believe a typedef for a pointer or atomic type is a Good Idea.

Re: Goodbye, Clean Code (2020)

#222

Earlier quoted context omitted.

The thing that bothers me about conversations in opposition to "best practices" or "clean" code" is that it misses the pragmatic aspect of those concepts. WHY do we write clean code? Because the value of software is its ability to CHANGE. Otherwise we would stick with fixed circuits. Best practices and clean code don't exist in a vacuum and they are not floating abstractions that developers should throw around as if…

Overly abstracted code can be difficult to read, comprehend, maintain and reason about. Thousands of small methods spread through hundreds of FactoryFactoryFactories and Builders and Adapters and Visitors can become a maintenance nightmare.

Overly abstracted code, or code that is a maintenance nightmare, is not clean code.

It's almost like you didn't even ready my comment, or completely glossed over the "why do we write clean code" part. Clean code is code that is easy to understand and maintain. If you're describing the opposite then you're not describing clean code.

Re: Goodbye, Clean Code (2020)

#223

Duplicated code != Messy code. The only time duplicated code is bad is when there is an actual logical requirement for the multiple instances of duplicated code to be the same. Like some actually underlying concept linking the duplicated code sections that is worth abstracting. That is not always the case. Just as often IME the situation is actually, "these two things happen to have the exact same behaviour right now…

I think that the problem of this article is the Dan equates DRY code with clean code. Dryer is not always cleaner.

Re: Goodbye, Clean Code (2020)

#224
post #201
post #114

It's weird that the author agrees with their sentiment. In my opinion, duplicating code is never the right answer. Using a different form of deduplicating would be the solution here. Just write a few functions that do the math and then call them, rather than create new abstractions that can later become monstrosities. I think they learned the wrong lesson here. Just my two cents :)

> duplicating code is never the right answer. Say you have (a*b+c)*2.0f+d several places in your code with potentially different a b c d variables. Are you really going to make up a new name for it as a function? It's much easier to just read the expression to know what it does than to memorize a new name for every possible small occasionally duplicated expression.

[deleted]
Post reply on HN