Author: Robert C. Martin · Published: 2008 · Genre: Programming, Software Engineering
Clean Code‘s biggest strength is that it makes you care about readability: after it, you will never again name a variable d or write a 300-line function without flinching. Its biggest weakness is that its rules harden into dogma, and several of its own worked examples are harder to follow than the code they replace. Read it early in your career, but read it skeptically and with a second opinion on hand.
The core ideas
Martin, known as “Uncle Bob”, wrote a Java-centric handbook of coding habits, with several chapters contributed by colleagues. The advice that matters most:
- Names should reveal intent. Prefer elapsedTimeInDays to d. Avoid noise words (a ProductInfo class next to a ProductData class tells the reader nothing), choose pronounceable and searchable names, drop Hungarian notation and member prefixes, use nouns for classes and verbs for methods, and keep one word per concept.
- Functions should be small, and then smaller than that. Each should do one thing at one level of abstraction, and a file should read top-down, each function followed by the lower-level ones it calls (the “stepdown rule”). Martin says functions should hardly ever reach 20 lines, and the body of an if or while block should ideally be a single function call.
- Few arguments, no surprises. Zero arguments is ideal, one or two are fine, three should be avoided, and more needs special justification. A boolean flag argument signals a function that does two things. Functions should have no hidden side effects, should either change state or answer a question but not both (command-query separation), and should throw exceptions rather than return error codes.
- Comments are mostly a failure to express yourself in code. Rewrite unclear code instead of explaining it, keep legal, intent and warning comments, and delete commented-out code.
- The Boy Scout Rule: leave every module a little cleaner than you found it, protected by fast, independent unit tests written test-first.
What’s great
The naming chapter is still the best short guide to the subject, and it has aged well. The catalogue of smells and heuristics in chapter 17 works as a code-review checklist. The error-handling advice, such as not returning or passing null, prevents real bugs. And the core message, that code is read far more often than it is written and that mess slows whole teams down, is correct and was badly needed in 2008.
What’s weak
The rules are stated as absolutes, and followed literally they produce code that is worse, not better. Chopping logic into dozens of two-to-four-line functions scatters one idea across a file. In his widely shared 2020 essay arguing it is time to stop recommending the book, the writer qntm showed that the refactored FitNesse example, SetupTeardownIncluder, is full of private methods that quietly modify member variables, exactly the hidden side effects the book warns against. The PrimeGenerator example, with method names like smallestOddNthMultipleNotLessThanCandidate, draws similar fire.
John Ousterhout, author of A Philosophy of Software Design, debated Martin in writing between 2024 and 2025 on method length, comments and test-driven development. Ousterhout’s rewrite of PrimeGenerator as one well-commented method is, to my eye, far easier to follow. In 2023 the game programmer Casey Muratori showed that the book’s preference for polymorphism over switch statements made a simple benchmark markedly slower, while a plain table-driven version ran around ten times faster.
The examples are also mid-2000s Java, with almost nothing on functional programming. A rewritten second edition published in 2025 adds examples in languages including Go, Python and Clojure, but the first edition remains the one most people are handed.
Who should read it
Junior developers and bootcamp graduates will get the most from the chapters on naming, functions and error handling. Treat the rest as one strong opinion, not law, and read A Philosophy of Software Design next for the counterargument.
Rating: 3.5/5
Image credits — Featured image: Photo by Nangialai Stoman on Unsplash. In-article images: Photo by Alex Qian on Pexels; Photo by Chris Ried on Unsplash.
