Last week, I shared with you Jan’s answer to the question: “What is clean code for you?” Today, I have the honour to share the answer by Benjamin Bouvier (let’s call him Ben), also engineer at Mozilla.
The word “honour” may seem pompous, but I am not using it lightly. To be honest with you, when Ben and I were both students in the same class at university, I was a bit intimidated by him. In my studies and in the various companies I’ve worked for, I’ve met plenty of smart people. But I’ve rarely met people that we could put in the “genius” category. Well, Ben is one of them (sorry Ben to make you blush, but this is just the way I consider you!).
No matter in which room we were, and regardless of its size, Ben always seemed like the smartest guy in the room. I’ll share two vivid memories to illustrate what I mean.
The first was during an advanced math class. The whole class was given some time to solve an exercise. After the allocated time, the teacher asked whether anyone found the solution and could share it with the class. Awkward silence. We all looked clueless. Until Ben raised his arm and said that he would give it a try. He went to the chalkboard and detailed the solution, making it seem trivial. We were all astounded, even the teacher.
The second was during a little project on PL/SQL. We had four hours to do it, and it seemed impossible to finish (at least to me and my buddies). Well, not for Ben. He left before the session ended. As for me, I stayed until the end, unable to finish. And guess what, he got the maximum grade (20/20 in the French system)!
I feel stupid today to have been intimidated by him, since there’s of course no correlation between one’s IQ and one’s character. When I got back in touch with him a few months ago, I was genuinely impressed by how nice of a guy he is, humble and approchable. So I just wanted to take advantage of this blog post to pay a tribute to a guy who never used his big brain to feel smug or superior to his peers. Thanks Ben for this great example.
Okay. Enough compliments for today! Let’s move on to Ben’s definition:
Code is a means to an end: putting an idea into motion. Those who write code rarely do it on their own, so code is to be shared; in this mindset, clean code is the one that’s easy to reason about in a group setting. I believe, almost in a dogmatic way, that each piece of code has a minimalist, pure and simple canonical equivalent, towards which we do (and must) tend as code writers.
It is minimal because every part that could be factored out is; and every clumsy refactoring that would prove superfluous isn’t there, making it minimal in the most maximal way. The code is always synchronized with the tests and the documentation, because these are part of or directly generated from the code itself. “Perfection is achieved not when there’s nothing more to add, but when there’s nothing left to take away” (Antoine de Saint Exupery).
It is pure when each attribute or function name corresponds to such a precise idea that there’s barely a need to look at the definition of some entity to understand what it does. Just looking around the context is enough. It goes straight to the point. Various contracts, expliciting invariants and expectations, are detailed and enforced through the use of debug assertions and other sanity checks.
It is simple in the sense that it puts related ideas together and separates ideas that are different. There aren’t too many nested levels of decisions (which map to nested control flow structures and indentation levels). It doesn’t raise doubts. Simple doesn’t mean inefficient, and every efficient algorithm that’s not trivial is thoroughly justified (why it is there) and explained with a detailed comment (how it is done). There are no clever hacks in this code, even in a temporary fashion, because temporary too often ends up in production code.
Clean code is alive. If it’s not running in production and not tested, then it’s dead code and it should be removed, because it’s an annoyance to the eyes of a reader (and versioning systems are pretty efficient at resurrecting dead code). Any code writer should not fall in love with their code, and should appreciate more than anything that it be reduced, if not removed: it is “just” a tool.
Well, not much to add on my part frankly since this answer is very comprehensive.
After Ben sent me his answer, I told him that I felt it to be almost “poetic”. He was describing clean code the way an architect describes a beautiful building or a painter a masterpiece. I told him that clearly, these were the hallmarks of a “software craftsman”, for whom code is not just a bunch of techniques but also an artform. I liked his reply, which I translated below:
I’m not sure that “craftsman” really describes who I am. I’m actually just passionate about this topic (and also keen on quality since as far back as I can remember). But we also have to remember that this definition describes an ideal. In real life, things are different. I feel this clearly even when I work on my side projects, where I’ve got more freedom to do things my way. It’s always a trade-off between this ideal quality and more pragmatic constraints.
As for me, the longer I work as a developer (and especially on large codebases), the more I see “clean code” and code quality as a fundamental necessity to keep our sanity and satisfaction. Without them, this job can become really frustrating.
So let’s strive towards that ideal, not because we want it, but because we need it!