4 ms·

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 b

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.

esafak 3y ago
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?
- doctorpangloss 3y ago
  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.
ctvo 3y ago
> 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 https://www.wsj.com/articles/BL-LB-4558
- gizmo 3y ago
  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).
  - f1shy 3y ago
    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”
    - gizmo 3y ago
      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/include/__compare/compare_strong_order_fallback.h https://github.com/llvm/llvm-project/blob/main/libcxx/includ... https://github.com/llvm/llvm-project/blob/main/libcxx/include/__algorithm/find_end.h https://github.com/llvm/llvm-project/blob/main/libcxx/includ... Is this "clean code"? I'm confident there will be absolutely no consensus.
      - ecnahc515 3y ago
        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.
SideburnsOfDoom 3y ago
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.
kinonionioa 3y ago
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".
- bumby 3y ago
  “All [clean codebases] are alike; each [ugly codebase] is [ugly] in its own way.” -Leo Tolstoy
- shiroiuma 3y ago
  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.
- throwaway2037 3y ago
  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.
  - munksbeer 3y ago
    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.
bumby 3y ago
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.
oweiler 3y ago
Devs also overestimate the difference their "clean code" actually makes. Architecture is much more important.
- gazonk 3y ago
  Totally agree.
hiepph 3y ago
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".

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.

esafak 3y ago

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?

doctorpangloss 3y ago
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.

ctvo 3y ago

> 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 https://www.wsj.com/articles/BL-LB-4558

gizmo 3y ago
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).
- f1shy 3y ago
  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”
  - gizmo 3y ago
    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/include/__compare/compare_strong_order_fallback.h https://github.com/llvm/llvm-project/blob/main/libcxx/includ... https://github.com/llvm/llvm-project/blob/main/libcxx/include/__algorithm/find_end.h https://github.com/llvm/llvm-project/blob/main/libcxx/includ... Is this "clean code"? I'm confident there will be absolutely no consensus.
    - ecnahc515 3y ago
      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.

SideburnsOfDoom 3y ago

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.

kinonionioa 3y ago

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

bumby 3y ago
“All [clean codebases] are alike; each [ugly codebase] is [ugly] in its own way.” -Leo Tolstoy
shiroiuma 3y ago
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.
throwaway2037 3y ago
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.
- munksbeer 3y ago
  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.

bumby 3y ago

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.

oweiler 3y ago

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

gazonk 3y ago
Totally agree.

hiepph 3y ago

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