Since starting this blog, I’ve had the priviledge of interviewing a few software developers I respect, with one simple question: What is Clean Code for you?
Since I’ve put the series on hold for a few months, here are a refresher of the articles so far:
- Intro to the series and answers from giants from the book “Clean Code”
- Jan, Senior Software Engineer at Mozilla
- Ben, Compiler Engineer at Mozilla
- Emilien Pecoul, Software Craftsman
- Bill Sourour from Dev Mastery
In June from last year, I sent an email to Cory House, a pretty famous and in-demand developer, so I didn’t really expect a response. I’ve tried in the past to do the same with other notorious developers, who never came back to me (and that’s fine, they must receive hundreds of emails per week from strangers with all kinds of requests).
So I was delighted to see him provide an answer, in only one sentence. But before sharing it, here are a few words on Cory, from his Pluralsight profile where he’s a popular teacher:
As for my relationship with Cory, I’ve been following him for almost two years on Twitter and Medium and have been regularly encouraged to grow both as a developer and a human being as a result. I’ve also listened to a few interviews from him on various podcasts and followed one of his courses on Becoming an Outlier.
If you haven’t heard from him yet, I’d encourage you to take a few minutes to check some of his resources available online and follow him on Twitter. This won’t be wasted time.
Okay, enough for the intro, here is his answer to the question: What is Clean Code for you?
Clean code clearly expresses the programmer’s intent in bite-sized pieces that can be reasoned about in isolation.
That’s it. That’s indeed an answer that clearly expresses Cory’s intent in a bite-sized piece that can be reasoned about in isolation, right? 😋
So let me walk you through the answer.
Clean code is clear…
Actually, I wonder why we’re using the adjective “Clean” when talking about code. To me, “Clean Code” is all about clarity. We could rename the movement and call it “Clear Code” instead of “Clean Code”.
When I need to dive in a new codebase, the best gift the original writers could have left me is clarity. It’s again the same as with writing prose.
It expresses the programmer’s intent…
And what is clarity but simply transparence about the author’s intent?
When trying to understand code I didn’t write, the most common and frustrating questions that come to me are: But why? Why did you write this that way? What did you mean? What were you thinking?
Clean code doesn’t leave you wondering. It uses the chosen language’s idioms and best practices to translate intent into code.
All the variables and functions are carefully named to reflect what they’re referring to. Good naming is key. Just the right combination of words with the right nuance so that the meaning becomes unmistakable. It simply cannot mean something else in its context. No ambiguity can be tolerated.
The cleaner the code, the less questions a reader needs to ask himself to understand it. You feel like you are in the author’s mind.
Yet again, we see that writing good code is all about being a good communicator. We write code for humans before writing it for machines. We write to be read and understood.
It’s almost impossible to be a clean coder and yet not be able to communicate clearly with other human beings. The two go hand in hand. The myth of the lone coder in a cave with long hair needs to die. These folks are most likely not clean coders. They may get things done for sure, but having to dive into their codebase would be a nightmare for most of us.
…in bite-sized pieces that can be reasoned about in isolation
Another key ingredient to clean code.
I still remember vividly the time I had to dive into a huge codebase where some files had more than 10,000 lines and where some functions were hundreds of lines long.
To understand the logic, I had to start at the top, put my headphones on, and struggle through a jungle of cascading for loops and if statements.
In his book Clean Code, Bob Martin says the following:
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long.
When you look at some of the most successful open source projects on Github, you’ll be hard pressed to find functions longer than 20 lines. Here’s an example from the source code of Visual Studio Code, the editor I’m using to write this article. Even if you are not familiar with this codebase, you can quickly make sense of the logic since the functions are clearly named and short.
@Cory: Thank you so much for having granted my request. It’s an honour for me to publish your answer. Thank you also for sharing the wisdom you’ve gained through the years with thousands of “hungry” developers like me. I hope my commentaries mainly represented what you had in mind. If not, please do not hesitate to correct or clarify.