Over the years my perception of what clean code really is has changed somewhat. The idea of this blog is to pinpoint exactly what I currently think clean code is, in the hope to revisit it in the future and determine whether my opinion has changed.

Inspiration

The book Clean Code by Robert C. Martin is arguably the most important programming book ever written, if you haven’t read it, you’re doing yourself a disservice. I’d argue it’s the one book every programmer must read!

In the opening chapters, the author asks several successful programmers what they believe makes code clean. They all give different answers, and I agree with every one of them. One of my favourites is Grady Booch’s take:

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward line of control

My thoughts on clean code

Clean code is simple. It’s exactly how you think you’d have written it. The code is testable — with abstractions in the right places — and thoroughly tested. I’ve never seen clean code that isn’t covered by a suite of unit tests. Whether this is because the act of writing unit tests produces clean code (red, green, refactor) or that the type of engineer that writes tests tends to yield better code, I’m unsure. You can tell from reading clean code that the architect truly cares, it’s their craft, and they’ve toiled over each line in agonising detail — which may be why I couple clean code with tests.

Clean code does one thing and does it well. It is expressive, containing meaningful variable/method/class names. It reads like a top-down narrative the lower you go the lower the abstraction, with each method containing a single level of abstraction. You need not dig deep into the code to understand its intent, the method names articulate the context so you focus on what needs to be done.

In The Pragmatic Programmer David Thomas and Andrew Hunt talk about the broken window theory:

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.

We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

I believe clean code to has opposite effect. If a programmer has been tasked to extend a particularly well-written module, they’ll likely take extra care to ensure their code fits in nicely, to continue the cleanliness.

A funny but true metric to determine how clean the code is, is the number of WTFs/minute, the fewer WTFs, the cleaner the code:

I’m interested to hear what clean code is to other engineers. Everybody tends to have slightly different answers to this question, and it’s interesting to hear how developers from different industries working on varying platforms determine clean code.

If you liked this blog then please sign up for my newsletter and join an awesome community!

Also, I currently run a completely free Planning Poker website that is gaining quite a lot of traction. If you work in a dev team and do biweekly sprints, give it a go and let me know if there’s anything you’d like added. You can also get involved, the code is completely open-source.