Overview
"Clean code" is the umbrella term for the craft principles that keep code readable and cheap to change: code is read far more often than it is written, so optimizing for the reader is optimizing for the team. The label comes from Robert C. Martin's book, but the body of practice is wider (Fowler, Ousterhout, A Philosophy of Software Design) — and worth studying critically, not as dogma.
Key points
- Naming carries design: intention-revealing names for variables, functions, classes; a name that needs a comment is the wrong name.
- Small units, one responsibility: functions that do one thing at one level of abstraction; classes with one reason to change.
- SOLID: Single responsibility, Open/closed, Liskov substitution, Interface segregation, Dependency inversion — the last one is the foundation of hexagonal architecture.
- Comments explain why, code explains what: prefer refactoring to commenting; keep the comments that state constraints code cannot express.
- Errors are part of the design: exceptions vs. result types, fail fast, no silently swallowed errors.
- The counter-current: Ousterhout argues for deep modules (small interface, big implementation) and warns that over-fragmenting into tiny functions can hurt comprehension — clean code is a trade-off conversation, not a rulebook.
- To explore: cognitive load as the unifying metric, code review as the enforcement loop, "Tidy First?" (Beck).
Practice
- Tennis Refactoring Kata (source) — an hour inside someone else's mess; naming and small-unit cleanups toward readable scoring code.
- Code smells catalog (source) — recognition drills: pick a smell, hunt it in your current codebase, name the fix.
- Racing Car katas (source) — one small exercise per SOLID principle; refactor each until the violation is gone.
- Exercism (source) — small exercises with mentor review: feedback on readability from an actual reader, the metric that matters.
- Gilded Rose — legacy rescue (exercise) — take unreadable code to clean under a safety net, then prove it by adding a feature.
Related
- Refactoring techniques — how code gets clean.
- TDD — the feedback loop that keeps it clean.
- Hexagonal architecture — the same principles at application scale.
- Coupling & cohesion — the forces SOLID operationalizes at class scale.
- Covariance & contravariance — Liskov substitution and interface segregation as the type system enforces them.