Live data from Hacker News

Goodbye, Clean Code (2020)

overreacted.io

121–130 of 224 posts

Re: Goodbye, Clean Code (2020)

#121
This post is such a breath of fresh air! I'm glad I'm not the only one who has come to realize that a lot of "clean" code is actually just developers trying to be clever or scratch an itch of obsessive-compulsion.

Repetition isn't necessarily a bad thing. If the repetition isn't difficult to alter and it more clearly describes what is happening on a step by step basis, it's difficult for me to call that "dirty".

Code is for humans, not computers, first and foremost. Certain things necessitate performance early on, but for a lot of projects it isn't reasonable for all code to make absolute logical sense from the get-go. What's more important is that people can read the code and understand it without undue deciphering.

Sometimes I come back to code that I've written long ago. When I wrote that code, I almost always thought I was writing "clean code". It often turns out that the code I was immediately able to understand and make changes to was the code that had repetition, wasn't mindlessly spread out into a bunch of "tiny functions", and had comments spread out to describe my reasoning.

In contrast, "clean" code is often inherently hard to change because it relies on centralizing functionality. When you centralize something and you change it, it may work for one circumstance but mysteriously cause something else to break. With repetition, your code base might be larger but code may be more decoupled and thus easier to make a small change to fix one thing without breaking another similar thing.

Re: Goodbye, Clean Code (2020)

#122
I disagree with the author, who says "My code traded the ability to change requirements for reduced duplication, and it was not a good trade." I think this is a great trade, because the number of times I've seen errors resulting from duplicate code is FAR greater than the number of times I've had to kludge an abstraction because of changed requirements.

Re: Goodbye, Clean Code (2020)

#123
post #71
post #60

Earlier quoted context omitted.

There are only two hard things in Computer Science: cache invalidation and to know when not to use abstraction.

But what about naming things

Maybe the wrong thing was invalidated from the cache of hard things in computer science.

Re: Goodbye, Clean Code (2020)

#124
post #48

When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. I don't think assuming people who disagree with you lack confidence and are "compensating" is an effective way to reach an audience. Rewriting your teammate’s code There should be no such thing as "your teammates code", there is only your team's code. If the changes were…

To be honest, i found these values touted, to be the signal of the worst kind of subjective code, leading to endless "battles" between subjective "better" code styles and bitter endless "but mine is more logic"-debates where the subjectiveness of ones opinion is not even perceived.

I had programers on lousy toolchains argue for the 9000 codeline one-file copy paste monolith, because it was "objectively" easier to debug.

There is always a teammates code, who will be different.

Re: Goodbye, Clean Code (2020)

#125

I'm shocked that from all discussion nobody noted the root of all evil: "It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code." No PR, no code review, no CI. Just a cowboy pushing to the master..

> No PR, no code review, no CI. Just a cowboy pushing to the master..

Let's be clear that the dangers here are "no code review" and "no CI".

The others are fine in most circumstances, unless you work on some huge monolithic codebase.

Smaller cross-functional teams should be able to push to master to solve problems then and there without everyone's unanimous approval, and everyone should feel enough safety to be able to make changes to the codebase they share with their team.

The real "root of all evil" is why is someone working against the team from within the team?

Re: Goodbye, Clean Code (2020)

#126
The “duplicated” example seems to me to be similar to an inherited class. An abstract class defines the interface Rectangle, has resizeTopLeft, etc. and you implement the interface.

It’s not duplication at this point.

edit: I’m an idiot. Perhaps not making it an abstract class. But it’s one of those examples where inheritance might actually help.

Re: Goodbye, Clean Code (2020)

#127

Earlier quoted context omitted.

And using clean code wrong. Clean code is not a panacea. If people use it as such and without the correct agile rites, they should do it at their own peril, but blaming it on clean code is at the very least naive (and somewhat dishonest)

Personally, I disagree that DRY is the same as “clean”. Clean code is merely code that has been thoughtfully structured (regardless of repetition) and is relatively transparent as to its purpose.

I've seen a few developers see multiple "duplicated" API formats for instance (for different API's) in the same codebase and think those are "duplicated" and then entangle two completely separate API's together. This is worse IMO

Re: Goodbye, Clean Code (2020)

#128

I'm shocked that from all discussion nobody noted the root of all evil: "It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code." No PR, no code review, no CI. Just a cowboy pushing to the master..

This is just how some places work, unfortunately.

We all push to main, no code reviews, no CI etc.

Hell, some people here patch things by downloading the live dll, decompile, update code, recompile and stick it back to live...

Re: Goodbye, Clean Code (2020)

#129
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." It's important to recognize that there may be no guarantee that will be the case *in the future*.

If the reason for the duplicated code is just coincidence, let the code be duplicated. You'll give the duplicated code sections freedom to drift apart naturally as requirements change and save yourself the trouble of having to decouple things later.

Re: Goodbye, Clean Code (2020)

#130
post #13

"Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it." While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction. "Goodbye, Clean Co…

HN has a lot of people who seem to benefit from these types of “common sense” articles that bury the lede, judging by the fact they appear on the front page so frequently. (Putting common sense in scare quotes to acknowledge that this is new information to some, no matter how obvious to others)

I'd suspect it's more a matter of people enjoying the sense of validation they get from an article which tells them that the low standards they're accustomed to from work are good, actually.
Post reply on HN