Code Cleanliness

A recent online discussion critiquing the oversimplification, polarisation and moralisation associated with the label clean code repeated a common misconception around the term, namely that it was coined by Robert Martin. He popularised it and associated it with a specific approach in his Clean Code book, but he is not the originator of the term. Although absent from his writings before that book, it was certainly in use by many others long before Clean Code was published in 2008.

Prior to becoming considered a brand or a dogma, cleanliness and cleaning of code was a suggestive and general metaphor rather than a specific checklist of practices and judgements. Talking about ‘clean code’ was more along the lines of ‘clean clothes’ or ‘spring clean’ than ‘clean eating’ or ‘clean desk policy’, with their justifiably negative associations. The term clean code was no more concretely defined or rule-based than, say, tidy code.

For example, we find it in the opening sentences of Kent Beck’s 2003 Test-Driven Development book:

Clean code that works, in Ron Jeffries’ pithy phrase, is the goal of Test-Driven Development (TDD). Clean code that works is a worthwhile goal for a whole bunch of reasons.

We also find it in Martin Fowler’s 1999 Refactoring book:

I’ve not succeeded in pinning down the real birth of the term refactoring. Good programmers certainly have spent at least some time cleaning up their code. They do this because they have learned that clean code is easier to change than complex and messy code, and good programmers know that they rarely write clean code the first time around.

With the metaphor being used extensively throughout, for example:

The compiler doesn’t care whether the code is ugly or clean. But when we change the system, there is a human involved, and humans do care.

Use of this metaphor, however, is not confined to XP practitioners or the software craft lexicon. For example, in 2011, The New York Times’ obituary for Dennis Ritchie:

Colleagues who worked with Mr. Ritchie were struck by his code — meticulous, clean and concise.

But predating any of the uses I’ve already mentioned is what I believe was my first encounter with cleanliness in code:

The best documentation for a computer program is a clean structure.

And clean code:

We will say it once more — clean code is easier to maintain.

These quotes are from Brian W Kernighan and P J Plauger’s 1978 book, The Elements of Programming Style (2nd edition). Although already dated when I first read it — examples are in FORTRAN 66 and PL/I — this book had a profound influence on how I thought about code — formatting, meaningful names, comments, boundary and error conditions, logic and control flow, regularity, refactoring and more. I borrowed it during my first job after university and bought my own copy a few years later.

You can also find these quotes in the first edition, which was published in 1974. The idea of clean code has been around in one form or another for at least half a century.