By ByteBot
Clean Code by Robert C. Martin is one of the most influential programming books ever written. It’s also giving terrible advice. For 15 years, developers have treated it as gospel—writing 2-4 line functions, eliminating all comments, and abstracting everything. The result? Code that’s measurably slower, harder to understand, and more difficult to maintain. Performance engineers have the benchmarks to prove it.
The Performance Disaster
Casey Muratori, a performance engineer, ran the numbers on Clean Code’s core principles. Following the book’s recommendation to use polymorphism instead of switch statements costs you a 1.5x performance penalty—35 cycles per operation versus 24.
Clean Code’s information hiding principles prevented optimizations that would deliver 10x better performance. When Muratori violated Clean Code’s rules and used a table-driven approach, performance dropped from 35 cycles to 3.5 cycles. Adding a second property while maintaining Clean Code principles resulted in code that ran 15 times slower. As Muratori put it, “This is like pushing 2023 hardware all the way back to 2008.”
These aren’t theoretical concerns. When fully optimized code ran 20-25x faster than the “clean” version, it became clear: Clean Code’s abstractions actively prevent optimizations.
The DRY Trap
Don’t Repeat Yourself sounds sensible until you take it to extremes. Two code blocks that look similar today get forced into a common abstraction, even when they serve different purposes.
Picture this: Facebook and Instagram both have APIs to create social posts. They work the same way today, so a DRY purist extracts “common post creation logic.” Then Instagram adds filters and stories. Suddenly that abstraction needs flags, parameters, and conditional logic. The shared code becomes more complex than the duplication it replaced.
There’s a better approach: the WET principle. “Write Everything Twice” forces you to see a pattern appear twice before abstracting it. Sometimes duplication beats the wrong abstraction.
Comment Phobia Loses Critical Knowledge
Robert Martin declared that “comments are a failure.” According to Clean Code, good code is self-documenting. Stanford Professor John Ousterhout calls this “a beautiful lie.”
Code shows what and how, but it can’t show why. Why was this approach chosen? Why does this business rule exist? What gotchas did previous developers encounter? That context lives in developers’ heads, and when they leave, the knowledge disappears.
A meta-study of over 60 academic papers found that documentation shortens task duration, improves code quality, and increases productivity. Documentation typically represents 11% of developer work hours—not wasted time, but valuable context.
The irony? Even Clean Code itself contains comments. Martin’s prime generator example has hidden side effects that would be invisible without documentation.
The 2-4 Line Function Fallacy
Martin argues the ideal function is 2-4 lines of code. This creates “lasagna code”—thin layers of abstraction stacked so deep you lose track of what’s happening.
Human working memory holds about seven items. When you’re navigating dozens of 2-line functions, constantly context-switching, you exceed that capacity. The abstractions that were supposed to improve readability instead make code harder to understand.
John Ousterhout’s “A Philosophy of Software Design” takes the opposite approach: favor fewer, deeper modules. Excessive decomposition increases interface complexity, especially when methods are tightly coupled.
Cargo-Cult Programming
Clean Code’s dogmatic presentation creates cargo-cult problems, particularly among junior developers. The book states absolute rules without discussing trade-offs. Apply these rules blindly and you get interfaces with single implementations, functions split for no reason, and code reviews enforcing ideology.
Junior developers read that every class needs an interface, so they create unnecessary abstractions. They read that functions must be tiny, so they fragment straightforward logic. Code reviews become battles over doctrine: “This function is too long” regardless of context, “This violates DRY” without discussing whether duplication is appropriate.
What to Do Instead
Context matters more than rules. Clean Code gets some things right—meaningful names, consistent formatting, single responsibility—but these need nuance, not dogma.
When performance matters, profile your code. When readability matters, sometimes duplication is clearer than forced abstractions. When maintainability matters, write comments explaining why, not just what.
Better resources exist. John Ousterhout’s “A Philosophy of Software Design” provides evidence-based design principles. “The Pragmatic Programmer” emphasizes context over absolute rules. These books acknowledge that pragmatism beats purity, and shipping working software matters more than theoretical perfection.
It’s time to move past the dogma toward an approach that values understanding over ideology, pragmatism over rules, and measured improvements over cargo-cult abstraction.
