This post is about the wonderful book Clean Code by Robert Martin. Clean Code changed the way I write code. If you have a look at the code I produced over the last couple of years, you can tell the code before I read Clean Code from the code after I read Clean Code. It’s that big a difference.
This post isn’t a summary of Clean Code. It’s about the principle behind Clean Code: Code is meant to be understood by humans.
You might think, “Wait … the purpose of code is to be executed by a machine.” That’s obviously true. But if it were about the machines, there would be no need for the fancy programming languages we use. The computer doesn’t care about classes, lambda expressions or generics. It doesn’t care about how you name methods or variables. It doesn’t care if you split your code into multiple small files or if you stuff everything into one enormous file. In fact, the computer doesn’t care about most of the things we spend our time pondering about. That’s why we have to compile the code we write. The compiler gets rid of all the bells and whistles we’ve put so much effort into, when it brings the code into a format the computer does care about. Well then, why do we spend so much time caring about things that get erased during compilation anyway? Because it’s not about machines, it’s about humans.
I got that without reading Clean Code. We have high-level programming languages to make writing code easier. What I didn’t get - or didn’t care enough about - is that I’m not alone. Enterprise software development is a team sport. It’s not sufficient that I understand the code I write, everyone on the team should able to understand the code I write. Of course, I can’t guarantee that everyone will understand the code I write, but it’s my duty to make it as easy for them as reasonably possible.
A quote from the book sums it up perfectly:
We are authors. And one thing about authors is that they have readers.
Good authors care about their readers. Clean code is easy to read, easy to reason about and easy to change.
The Subtitle Tells You More
Let’s have a look at the subtitle: A Handbook of Agile Software Craftsmanship. There are two important aspects.
Agile: Agile software development means constantly changing code. Before you can change code, you have to understand it first. We’re talking about enterprise software. That means there is a team of developers that has to deal with a large code base. In such a scenario it happens all the time that the one who has to modify a piece of code isn’t the one who initially wrote the code. Enterprise software is long-lived. The one who wrote it might have already left the company. That’s why clean code is an absolute must for enterprise software. If your code base is unintelligible, you’re in big trouble.
Software Craftsmanship: I’ll talk about software craftsmanship in another post. For now, just think of it as the difference between being satisfied with working code and striving for quality code. It means that you are willing to put some extra effort into your working code and turn it into clean code.
What’s to Gain?
Do you want to sell the idea of clean code to someone? Ok, here are two more selling points:
Clean code is fast to change: I already said that clean code is easy to understand and therefore easy to change. But it’s also fast to change. That’s important when you have to compete in the marketplace. Every new feature has to be integrated into the current system. You can do that a lot faster if you understand the current system.
Clean code tends to have less bugs: Did you ever change code you didn’t quite understand? I did. And let me tell you, that’s not a good idea. If you don’t understand the code you change, it’s only a matter of luck if you unintentionally break something else or not.
There’s another important aspect. If your code is easy to understand, you can reason about it with team members without explaining what the hell your code is even doing first. Talking about your code with others is a great way to reduce bugs.
Clean code cares about its readers. Clean code tells you what it does without hidden surprises. It’s pleasant to read and easy to change. In the next post I’ll give you some examples of clean code. We’ll talk about names, methods, classes and comments. And about how you turn working code into clean code.
A Final Thought
If you haven’t read Clean Code yet, read it!
How important is clean code? Essential for success? Or is working code all you need? Tell me in the comments.