1 minute read

The term is sometimes used to refer to a specific and opinionated way of writing code, the one described in the popular book “Clean Code” by Robert C. Martin. That book is now over 15 years old, and it contains some good advice along with lots of debatable, dogmatic and controversial advice. Often some of that advice is criticized with statements like “clean code is bad for performance” or “clean code is hard to maintain”. I find it problematic when the name of the book is confused with the concept of code that is clean. The adjective “clean” had already been used to refer to tidy, elegant, well-written code in books like The Pragmatic Programmer and Code Complete, both of which predate the Clean Code book. Also, there are many books about how to create clean code that are less dogmatic and don’t just copy the same advice from the Clean Code book, although they may have some overlap. When I see a well-written piece of code, I might say “that’s pretty clean” without comparing it to some book author’s guidelines.

I think we should be explicit when we criticize the Clean Code book (or someone else’s personal opinion on what well-written code looks like). We can also be more deliberate about when we capitalize the term (“Clean Code”) and when we are just talking about code that is clean (“clean code”). When someone suggests that we write code in a certain way, and we (and others) don’t find that clean/readable/maintainable at all, then it’s their suggestion that might be worth debating, not the whole idea of trying to create code that is obvious, flexible, easy to understand. “Clean” is not a formal, technical term. Let’s not surrender a normal word that has been in use since forever to a single controversial book just because it shares the same name.