A comprehensive critique of Robert C. Martin's 'Clean Code' second edition dropped this week, and the verdict is brutal: almost nothing from the original 2007 book's criticisms made it into the new version. The analysis, published on GitHub Pages and picked up by Hacker News readers, dissects Martin's revised text with surgical precision—and finds the legendary software development guide still riddled with the same problematic advice that sparked debates for nearly two decades.

Same Recipe, Different Cookbook

The reviewer notes a key structural shift: where the first edition was 'focused, concise and highly opinionated,' the second is an amalgamation of multiple Martin works—Clean Code, The Clean Coder, Clean Architecture, and SOLID material stitched together. It's thicker, full of digressions and rambling, but the actual code examples haven't meaningfully improved. Java samples remain 'abysmally bad' according to the critique, while new Python and Go chapters read like Java written with disclaimers: Martin literally writes 'I apologize - I am not an accomplished Golang programmer' in the source.

The Roman Numeral Refactoring That Says It All

The analysis zeroes in on Chapter 2's code cleanup exercise—a simple Roman numeral converter. The original version runs about 60 lines. Martin's 'cleaned' version explodes to over 100 lines across multiple classes, with instance variables storing what should be method parameters and constants allocated fresh on every call. The reviewer flags the confusion: class FromRoman has a static convert() entry point but its constructor remains public when it should be private. String pattern arrays get recreated constantly instead of being declared as static final constants.

Addressing Critics Without Really Answering

Chapter 10 tackles the book's most controversial recommendation—extreme function decomposition—and the critique finds Martin talking around the problem rather than solving it. He dismisses concerns about tiny functions drowning readers, obscuring intent, and hurting performance with language history tangents about Fortran and COBOL. The reviewer points out that objections one, two, and four are essentially the same concern dressed differently. When Martin does engage directly, he makes curious claims: 'allowing the individual methods to communicate without having to resort to passing arguments' gets flagged as strange phrasing since passing arguments IS how functions communicate.

The Double Slap

Here's where it stings most, per the analysis: if you reject Clean Code's style recommendations, you're left with worse performance AND worse readability. Extracted tiny functions mean more compiler work and garbage collection pressure. Passing data through instance fields instead of method parameters is slower in non-JITed Java code—meaning slower test runs too. The reviewer argues this trade-off only makes sense if you accept that the style improves clarity, which he firmly disputes: 'When you understand an algorithm, the artifacts intended to help you understand it become annoying.'

Key Takeaways

  • Second edition keeps the same problematic tiny-function philosophy despite years of community pushback
  • New Python and Go examples feel like Java with apologies attached rather than idiomatic code
  • Specific refactoring exercises introduce new problems: unnecessary allocations, confusing public APIs, instance variables where parameters belong
  • Martin debates Ousterhout on style and Muratori on performance but doesn't integrate their critiques into the actual code advice

The Bottom Line

'Clean Code' second edition is a missed opportunity wrapped in extra pages. Martin acknowledges disagreement exists while refusing to internalize it—the book reads like a greatest-hits collection from his other works rather than a thoughtful revision. If you're writing Java circa 2007 and want validation for verbose function names, this book's still got you covered. Everyone else should look elsewhere.