Clean Code

What it’s about

Robert C. Martin’s handbook of software craftsmanship. The first half sets out principles for readable code (meaningful names, small functions that do one thing, honest comments, clean error handling, tests as first-class code). The second half works through real Java code, cleaning it up step by step, and ends with a catalogue of smells and heuristics.

What I learned

Optimise for the reader. Code is read many more times than it’s written, often by someone in a hurry who’s trying to fix something at the end of a long day. Every naming and structure decision should make their job easier.

Names are design. If something is hard to name, it’s usually doing too much. Struggling for a name is a signal to split the thing, not to reach for Manager or Helper.

Small functions, one level of abstraction. A function that mixes high-level intent with low-level detail makes you read both at once.

The boy-scout rule. Leave the code a little cleaner than you found it. Not a rewrite, just one better name, one extracted function, one deleted dead branch, every time you pass through.

What I applied

I don’t follow every rule dogmatically any more; some of the advice reads as very 2008 Java. But the habits stuck, and they show up most in the unglamorous work:

• At Sky, a large React codebase had a long backlog of TypeScript errors, so the compiler had been switched off in the build. I worked it down to zero through months of small, non-functional merge requests, boy-scout style, then turned type checking on for good (Driving a TypeScript Codebase to Zero Errors).
• On the same platform I sped up the lint job several times over and added coverage indicators to every merge request, so quality was visible to reviewers rather than argued about (A Testing Strategy Teams Actually Adopted).
• At Accedo I proposed surfacing static-analysis results in pull requests, and introduced structured pull requests and review feedback, so “clean” became a shared standard rather than one person’s taste (Smart TV Apps on Low-End Devices).

The instinct I’d keep above all: make the code obvious to the next person, because the next person is often me.

A 2026 twist

The author himself has moved on: Uncle Bob now argues that humans shouldn’t read AI-written code line by line, but should specify it and verify it with deterministic tools. The reader the book was written for is changing (Don’t Read the Code? Verifying AI-Written Code).

Where it connects

Driving a TypeScript Codebase to Zero Errors · SOLID React · Bulletproof React · Refactoring · Practical Object-Oriented Design in Ruby