In the book Clean Code, Robert C. Martin (aka. Uncle Bob), asks several software-industry experts to define what clean codemeans to them. He elicits the help of thought leaders such as Bjarne Stroustrup, Grady Booch, Ron Jeffries, Dave Thomas, and Ward Cunningham. Their responses attempt to capture the subjective and elusive nature of what clean code is.
The definitions provided by these industry experts capture the key set of ideas behind clean code. They cover a wide range of important aspects including: simplicity, straight-forward logic, minimal duplication, single responsibility, and more. However, having spent many years reading about, practicing, and reflecting upon my own clean-coding practices, I would also like to add my thoughts to this on-going discussion.
For me, clean code is a philosophy of reader-centric code. It is about writing code for the reader of the code… not for the author… or the machine.
By writing for the reader, I mean that we need to start by understanding our audience and write our code with the reader of the code in mind, with each line of code that we write.
By not writing for the author, I mean that we (as authors) need to put aside our own personal desires, preferences, and egos and write our code for the needs of the reader, before our own needs as a writer.
By not writing for the machine, I mean that we should optimize code for human readability first, and only optimize for the machine when the cost of performance to the users outweighs the cost of a clean design to the readers of the code.
More precisely, clean code is reader-centric code that is simple, readable, understandable, testable, and maintainable.
“Programming is not about telling the computer what to do.
Programming is the art of telling another human what the computer should do.”
– Donald Knuth
The primary justification for investing in clean code is largely a cost/benefit argument.
Based on several sources I’ve seen (e.g. Bohem, Schach, and Glass) developers spend roughly 30% of their time creating code and roughly 70% of their time maintaining code. So we spend significantly more time, money, and effort in the software maintenance phase than we do the in software creation phase.
In addition, in the book Clean Code, Uncle Bob provides anecdotal evidence that we spend roughly 10% of our time writing code and 90% of our time reading code. While I haven’t been able to find empirical evidence to support this claim, it definitely matches my own intuition after 17 years of professional experience developing software.
As software developers, our primary objective is to maximize the return-on-investment (ROI) for the software we are creating for the business. We do this by minimizing the cost to create and maintain the software, while we maximize the benefit (i.e. the business value) that the software is providing to the users.
Clean code helps us increase the overall value, and reduce the overall cost, of both creating and maintaining software. It does this by focusing on creating reader-centric code that is simple, readable, understandable, testable and maintainable.
First, by creating code that is simple, we are creating only the code that is necessary to solve the problems of the business. We attempt to avoid any accidental or unnecessary complexity. This means that we are maximizing the value of the software without adding any unnecessary costs.
Second, by writing code that is readable, we are optimizing for the 90% of the time we are reading code, rather than the 10% of the time we are writing code. This is a significantly more cost-effective strategy than the alternative strategy of writing code as quickly as possible without concern for the readability of the code (which appears to be quite common in the software industry).
Third, by creating code that is understandable, we reduce the amount of time necessary to comprehend what needs to be done in order to extend, modify, or fix the software. Understandable code also reduces costs incurred by mistakes, bugs, and miscommunications caused by misunderstanding the intent of the code.
Fourth, by creating code that is testable, we encourage the automated testing of that code. Creating testable code and testing that code using practices like Test-Driven Development is the most effective way I know to improve the quality of the code, improve the long-term velocity of a team, and reduce the number of software defects. All of these factors contribute heavily to the overall return-on-investment of the software.
Finally, by creating code that is maintainable, we are optimizing for the 70% of the time/cost of maintaining code rather than the 30% of the time/cost of creating code. Moreover, we’re creating software that can much more easily evolve with the changing needs of the business. This is one of the biggest hidden values that creating clean code entails.
Ultimately, the economics behind investing in clean code are relatively clear and straight-forward in my opinion. In fact, the only real question, in my mind, is why clean-coding practices have not been more widely adopted yet in the software industry? The value of clean code seems fairly cut and dry to me.
It is my hope that the software industry will eventually evolve to a point where this set of practices will be taught to all new developers, expected of all professional developers, and supported by managers who grasp the economics behind the practices of clean code.
“Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.”
– Martin Fowler
There are several sources of information available on writing clean code.
Second, Uncle Bob has a Clean Coder video series that provides dozens of videos on clean code practices. The videos are a bit pricey, but they are still the best bang for the buck of any material on the subject that I’ve seen so far.
Finally, my website offers a variety of articles, presentations, videos, and courses on clean-code practices. Please feel to contact me if there’s anything that I can do to help you or your team improve you clean-coding practices.
If you’ve made it to the end of this article, I assume you’ve kept reading because you’re one of the developers that understands that there is a huge problem with bad and messy code in our industry.
I encourage you to go one step further and learn how to write clean code yourself. Then practice writing clean code each and every day. Finally once you’ve developed this craft, please become an advocate and teacher of clean-coding practices to your peers.
The only way we will fix this problem in our industry is if we are willing to invest the time to learn these practices ourselves, promote them to our peers, and explain (or defend) their value to the business.