Clean Code should die; long live Common Sense Code
Don’t get me wrong, there’s nothing wrong with the concept of “Clean Code” but it has become convoluted and misinterpreted and often used as some kind of elitism by hardcore followers.
As a CTO I often sit in on employment interviews and try to get a grasp of the applicants “view” on coding, and one of the biggest warning bells I can hear, is when the applicant starts cajoling about Clean Code and how it has changed his/hers life (well… or something like it).
Sometimes these discussions about Clean Code comes up after a walk-through of some code we have and the applicant (or consultant in some cases) gives the comment, as a general observation, that it’s not Clean Code, or “do you not follow clean code?”.
Then comes the discussion about what the persons view in Clean Code is, and it is often that mentioned convoluted and misinterpreted view I get to hear…
So, what is that view then, that I don’t like?
Well, there’s a few things, but first one would need to understand that coding is more like artistry than speaking a language (of code) and the “artist” (read; developer) wants to create something beautiful.
The problem with this is that all developers have their own “style” and views on what is “beautiful” and a big part of making the code readable and understandable to all in a team (or company) is to create a policy that all developers have to follow, perhaps hampering their “style”.
The policy should strive to incorporate the best “patterns” and suitable styles for your company and, most importantly, it should be set in the light of “Common Sense”.
How Common Sense and Clean Code differs, which is the point I am trying to make, is how it is interpreted.
The Clean Code evangelists mostly seems to sit and rant on `X` (f. Twitter), LinkedIn or similar social media and my biggest problem with the ranting is in regards to:
- Comments; there seems to be some sort of conception that your code must be so “clean” and well structured that comments are always redundant.
- One-liners; or rather trying to squeeze to much functionality into a short, overly complex line.
- Function length; I’ve heard a number of times that a function shall never be more than five line of code.
- Logging; Thy shan’t log! Ever!
As for comments, and that comments are always redundant if you write “clean code”; Not so, comments in code is an important part of making others understand what is going on (and also making you understand what you did when you come back a year later).
You can make a lot of “commenting” just by naming stuff correctly (according to Common Sense), e.g. the variable sum might be better explained by a better (and longer) name, like totalLineAmount making it more understandable without having to add a comment.
The “one-liners” are some kind of proof, or show-off, of how an awesome developer you are. Take this sample (in Node.js):
const clean = (obj, leave = ['string']) => Object.fromEntries(Object.entries(obj).filter(([, v]) => (['boolean'].concat(leave)).includes(typeof v) ? true : (v ?? false)));It’s a rather complex piece of code, with a very simple function, it’ll clean out any attribute in an object (on first level) that is null or undefined. It’s neither Clean (pun intended) or clear!
Now I have to confess that it is actually me who wrote that function some time back, and I am sure I was very proud of it at the time, but looking at it many months later I was, “what the heck, who wrote that and what does it do…?”, one Git Blame later and, I, myself, can consider I had fallen in the trap of “overcomplicating” it (probably) to impress whoever the poor sod was that did the PR review.
In hindsight the clean() function should’ve been broken up into a few lines to make the readability much better.
Just because you can write it all on one line, doesn’t mean you should!
Function length to a maximum of five lines is just ridiculous, it might work out in your tutorials or with a bunch of one-liners that nobody (including you) will ever understand again, but in the real world, my opinion is that a function doesn’t have a maximum length!
Sure, it should follow Common Sense, and be dived into separate calls for doing specific things, but just breaking it up to follow some notion about a function not being too long is plain dumb.
It is also very much harder to read and understand code if the chain of logic is broken up into a number of jumps that doesn’t make sense.
Logging is good, log often and log anything that’ll be useful in debugging an error!
That’s our Policy, it probably makes any Clean Code evangelist choke on their coffee but as we use Node.js (to 99%) logging doesn’t “cost” anything. However, manhours trying to recreate/replay problems/errors in a production environment costs a lot!
That’s why we log, and we log a lot, but again, according to Common Sense and with the thought if this is useful in finding a bug, or tracking down an error in production.
No code is flawless, it might look that way in your local environment or your sandbox running your one-liners, but in the real word there’s always some muddy water flowing through…
Again, I am not against Clean Code per se, the fundamentals of it is good and the idea fine, it’s just the interpretation I am turning against and what it is becoming…
