Clean Code is one of those books that almost every developer has either heard of or already read. Look at any list of coding book recommendations and you are likely to find Clean Code in there somewhere.
So is it really worth all the hype? More importantly, is it worth your time to read it? You shouldn’t read a book just because it features on some list online. Instead, use this guide to decide whether the book is suitable for your current situation.
- Book overview
- Who should read Clean Code?
- What questions does Clean Code answer?
- Useful things to know before reading Clean Code
- Complementary resources
Clean Code is based on the premise that poorly written code rots over time, and this becomes the single biggest consumer of time and effort in a software project.
The author therefore sets out to define what he believes represents clean code and the ways in which we can achieve it. He focuses on a few key areas:
- Functions, Objects, and Classes
- Error handling
- Unit tests
- Code formatting
There is also a chapter on concurrency and ways of implementing it cleanly, as well as a chapter on clean system design using Aspect Oriented Programming (AOP). Finally, the book finishes with a series of examples of the methods being applied to different pieces of code.
There is a somewhat common opinion that the second half of the book is less useful than the first. I broadly agree with this; the chapters on AOP and concurrency feel a little out of place in the book, since they are both topics which need more explanation than is given to them here.
Who should read Clean Code?
Clean Code is NOT for newcomers
I’ve read this book twice. The first time was just before starting my current job, which was my first time writing code professionally since leaving university. Reading it now, after getting a couple of years experience under my belt, has allowed me to understand the benefits of what is being taught a lot better.
A lot of people just starting out in programming will be looking for reading essentials and finding Clean Code in the list. Don’t get me wrong, there is a lot in here that is useful for those people, but whether they will be able to fully appreciate and use that information is debatable.
I think to really make the most of the lessons in the book, you should at least be an advanced beginner, if not competent.
Potentially not for those who have never worked with Java/OOP
If you have never written a line of Java or some similar programming language then you may find Clean Code a little alienating. While a lot of the advice given in the book is language agnostic, it often feels heavily coupled to Java. All the examples are written in Java, and many references are made to Java-specific libraries. If you aren’t comfortable comprehending Java code then the book could be a difficult read for you.
Java is the language of choice in this book because it is heavily Object-Oriented. Many of the recommendations made are specific to OOP, and so if you are not familiar with OOP concepts then you may feel that this book is not as relevant to you. The book makes plenty of assumptions about pre-existing knowledge as well, so you should prioritise building a baseline knowledge of Java and OOP before reading this book.
Those who want to learn good habits early
You may already have a good grasp of a programming language (ideally an OO one). If so, then this book is a great place to start learning to write clean, maintainable code. This is especially true if you have never written software as part of a team, since you will have had little feedback about your code.
Deliberately practising the advice given in Clean Code will teach you habits that will pay dividends throughout your career. People will be able to read and maintain your code with ease and you will be able to create products that you are proud to show off to others.
Those who want to learn to identify bad code and how to clean it
One of the strengths of the book, in my opinion, are the code examples. The author walks you through a section of code, looking for potential improvements. He then gives you his thoughts on what problems it has, and shows you how he would improve it.
Though real life is rarely as cut-and-dry as he makes out in these sections, there is a lot of value to be had from reading about an experienced programmer’s thought process in this way.
It is easy to fall into the habit of writing code that simply gets the job done and moving on. We could all benefit from learning to cast our eye over code in the way he does in the book. By doing so, we would all start to understand in more detail what makes for good or bad code and how to make sure that ours falls into the former group.
Those who want a high-level overview of the problems of concurrency
While a little out of place, I think that the message of the chapter on concurrency is an important one. You cannot avoid the issue of concurrency, and it is important that you design your code to handle it effectively.
The author does a good job of giving an overview of the challenges posed by concurrency and how we can be conscious of them when designing our systems. Anyone working with concurrent systems could do worse than to read this chapter, at least as a start.
What questions does Clean Code answer?
If you want the answer to any of the following questions, you can find them in this book.
- What makes code readable?
- Why is readable code important?
- How do I improve my naming?
- What does a good unit test look like?
- How do I write well-designed functions and classes?
- What are some challenges of concurrency and how can I implement it cleanly?
Useful things to know before reading Clean Code
As I mentioned before, I don’t believe that Clean Code is for absolute newcomers. The main reason for this is that the author makes a fair few assumptions about prior knowledge. There is no effort put into explaining any terminology used, so you should make sure you know about the following before reading:
This might go without saying, but there is a plenty of discussion about things like variables, functions, lists, arrays etc. If these words are not familiar to you then you should definitely not be reading Clean Code, and focusing on learning the fundamentals instead.
Clean Code is really about writing clean code in an Object-Oriented language. Clean code, in the case of this book, is code which is split into well-defined groups of related functionality, i.e. classes and objects that use interfaces and abstract classes.
Again, if these concepts aren’t familiar to you then the advice given in the book may not make much sense to you. See the complementary resources section at the bottom of this post if you would like an alternative perspective, or resources to learn about OOP.
Familiarity with SOLID
The author makes plenty of references to SOLID principles throughout the book. These principles are intended to encourage high-quality code design:
- Single-responsibility principle
- Open-closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
I wouldn’t say that this is essential knowledge to have before reading the book, but familiarity with the concepts will certainly allow you to get more out of it. The author does explain some of these concepts for you if you are completely new to them.
On the other hand, if you are very familiar with the SOLID principles then there is a good chance that there will not be much new in this book. It could serve as a good reminder of good practices in this case.
Again, I don’t think this is essential to get something out of the book, but it will make the code-reading sections a lot less painful.
- Head First Java, while a little goofy, is a great book for learning the fundamentals of Java and OOP. I think it would be a great precursor to reading Clean Code.
- The following blog post is a critique of the prescriptive tone of Clean Code. It encourages us to focus on enjoying our work over strict adherence to these rules. I like the idea the author mentions in the comments about deliberately writing “dirty code” from time to time, if for no other reason than to discuss it.