Highlights
- Code is read far more often than it is written — Martin's central argument is that readability is the primary economic property of a codebase, because every future change starts with someone understanding what's there. This is the SBM thesis in miniature: the value sits in the structure you leave behind, not in the cleverness of the moment.
- Names are the vocabulary of the system — the book insists that variables, functions, and classes should carry precise, intention-revealing names, so the code becomes its own explanation. That is a concept-library at code level: a shared, exact vocabulary that humans (and now AI) can navigate without a translator.
- Functions should be small and do exactly one thing — Martin pushes decomposition to the point where each unit has a single, nameable responsibility. This is the atomic-units principle applied to code: self-contained pieces with one clear purpose compose into systems; blobs don't.
- A comment is often an apology for unclear structure — rather than annotating confusing code, restructure it until the annotation becomes unnecessary. In MDDE terms: if you need prose to explain what an artifact does, the model behind it is underspecified — fix the model, don't decorate the output.
- Craftsmanship is a set of enforceable rules, not taste — Clean Code's lasting contribution is turning "good code" from an aesthetic judgment into named, checkable practices (the boy-scout rule, formatting discipline, small-scope heuristics). That is rules as the forgotten third pillar: quality that lives in explicit, repeatable checks instead of in the heads of senior people.
- Tests are the safety net that makes structure durable — Martin treats clean tests as first-class code, because without them nobody dares to keep restructuring. This is validate-don't-guess in its original habitat: a system stays changeable only when every claim about its behavior can be mechanically verified.
Highlights on this page are generated with the help of AI.