I’m going to say something controversial: Clean Code, the book, has done as much harm as good to the software industry. Not because Robert Martin is wrong, but because developers apply his rules dogmatically without understanding why they exist.
Before you close this tab – I’m not advocating for messy code. I’m arguing for a more nuanced view of what “quality” actually means in practice.
The Rules We Follow Without Thinking
Functions must be short. Names must be descriptive. Comments are a failure of expressiveness. No magic numbers. No side effects.
These rules exist for good reasons. But treating them as absolute laws leads to some genuinely bad outcomes.
The “Short Functions” Trap
I’ve worked in codebases where the Clean Code rule about small functions was applied so aggressively that a simple 20-line algorithm was split into 8 functions across two files. To understand what it did, you had to jump between files, reading function calls that abstracted away the actual logic.
The goal isn’t short functions – the goal is understandable code. Sometimes a 50-line function that does one coherent thing is more readable than six tiny functions with generic names like processData() and handleResult().
Comments Aren’t Always Failures
The idea that good code doesn’t need comments is right in the narrow case of explaining what code does. But comments are essential for explaining why.
# Bad comment (explains what, which is obvious):
# Loop through users and check their age
for user in users:
if user.age >= 18:
...
# Good comment (explains why, which isn't obvious):
# GDPR requires we store only users who have explicitly consented.
# The flag is set during the registration confirmation step.
if user.gdpr_consented and user.consent_date is not None:
...What Actually Matters for Code Quality
After ten years, here’s my more pragmatic list:
Correctness
Your beautiful, clean code is worthless if it produces wrong results. Test coverage and correctness trumps everything else.
Consistency
A codebase that consistently uses one mediocre pattern is better than one that has some Clean Code sections and some legacy sections and some experimental sections. Consistency means any developer can predict how things are done.
Understandability (Not Simplicity)
The goal is code that the next developer can understand quickly. This sometimes means short functions. Sometimes it means keeping related logic together even if the function is longer. Context matters.
Changeability
Good code is easy to modify without breaking things. This comes from good tests, clear dependencies, and avoiding cleverness.
The Real Advice
Read Clean Code. Apply the principles. But always ask: “Would the next person to read this understand it faster with or without this abstraction?” The answer should guide your decisions, not a rule from a book.
The worst code I’ve ever worked with wasn’t written by people who didn’t know Clean Code. It was written by people who followed it too religiously without thinking.