Hacker News Reader

Comment by manicennui | Hacker News Reader

The real problem is that "clean code" is completely arbitrary and if you ask 10 software engineers you'll get at least 5 different answers because this really boils down to preferences.

View on HN

> The real problem is that "clean code" is completely arbitrary and if you ask 10 software engineers you'll get at least 5 different answers because this really boils down to preferences.

I disagree. I'll take a bet that given 10 experienced software engineers (we can define what this means -- title, years of experience, familiarity with language idioms, etc.) they'll mostly agree on samples A, B, C, ... of code if it's "clean" or not.

Code doesn't have to follow my preferred design pattern to be clean. The bar is don't be shitty, and I'll know shitty code when I see it[1].

1 - https://www.wsj.com/articles/BL-LB-4558

I really doubt there is any such consensus. Some people really care about superficial code quality (good variable names; short functions; consistent formatting and documentation; compiles without warnings). Other programmers care mostly about architectural quality (shallow call stacks; correct data structures; few dependencies and little scaffolding).

As stated in the previous comment, if you give code from group A to group B, they will tell you “I would prefer this and that, but still seems clean to me”

I don't agree. I know what the previous comment said.

Modern C++ codebases that make extensive use of templates, inheritance, exceptions, type coercion, closures are considered clean by many because the code looks nice. But code like that can be a nightmare to work with, because of long compile times, spooky action at a distance, etc.

Take these two files from LLVM:

https://github.com/llvm/llvm-project/blob/main/libcxx/includ...

Is this "clean code"? I'm confident there will be absolutely no consensus.

It depends on the language. Some languages are just poorly designed and make it really hard to write anything that’s clean without trade-offs.

Writing good code requires good taste. Taste is subjective and cannot be easily codified. That doesn't make it arbitrary. Ask ten people about their favorite movie and they'll name ten different films, but I'd wager no one will say "Gigli".

“All [clean codebases] are alike; each [ugly codebase] is [ugly] in its own way.”

-Leo Tolstoy

I agree. The hardest thing I had to learn as a professional programmer: There are multiple styles of good taste. You need to be tolerant. When I look at some GitHub code reviews, I cringe at the number of pure aesthetic (aka low value) issues that people endlessly nitpick about. It is discouraging towards contributors.

I work on a team now where the three main contributors (including myself) all have _reasonably_ different programming styles (naming, whitespace, structure, const/immutable, algos). Having read enough code from the other two: I am confident they are good programmers, but their style is different from mine. Still, we try very hard to accommodate each other's style. When we make changes, we try to stay with the current style in the class / method. It has been a real learning experience for me.

This would be a hard no from me. I cannot stand having to switch style when working on the same codebase or even in the same company.

codestyle enforcement via pre-commit hooks or CI build failure is the way to go. Trying to adpat to codestyle is a distraction. All distractions should be removed when coding.

That's a bad analogy. People will certainly have different favorite movies, but they can also come to agreements on what's a "good" movie. There are a bunch of movies that I think are "good" movies in a more objective sense, but aren't my favorite things to watch. There are movies that I thought were excellent, but I have no desire to see again.

No, it is not. That is like saying art is objective so we can't say if anything is good or bad.

Don't you know a bad API, variable name, or architecture when you see one?

I agree with you. From experience, this pain is a red herring, it’s symptomatic of a specific kind of change: new features or bug fixes that require tight coupling of previously-authored-as-decoupled things. Clean code, architecture, whatever - it always falls over in the specific transition from decoupled-to-coupled.

Why do programmers hate making those changes? They always require tossing out a lot of existing code. So I guess I could say the antagonist is inertia. Certainly has been my experience interfacing with vendors and BigCo developers. If you have the ability to suppress this feeling, to delete stuff that works but is not correctly coupled to the new problem, you will thrive regardless of the architecture.

I disagree. While one can argue pointlessly over which code is the cleanest, it's very obvious when the code has a complete absence of it. I think of some 3000 line classes that I have met and done battle with.

The sibling comment that talks about "how quickly they can understand and use your code, and whether they can make changes without worrying about breaking things" is on the right track.

Devs also overestimate the difference their "clean code" actually makes. Architecture is much more important.

Totally agree.

The heart of your comment is true, but good organizations establish a set of standards for how they define clean code. At that point, it's no longer arbitrary.

But still, we should strive for writing the best "clean code" that we set out to write. So "clean code" here is subjective and bound to the individual. Normally, business and absurd deadlines force us to lessen that principle—that's what I call "ugly code".

Reply on news.ycombinator.com