The Clean Code is a book by Robert Cecile Martin, a pioneer of agile software craftmanship. This book was recommended to me last year on an Agile software development training by Cegeka in Belgium. I have read it and I must admit that it has had an impact on my work as a Java developer. Of course many similar books are available. But this is the first one of this kind I read.
In my company we had one hour lasting sessions, in which we read two chapters and discussed content of the book together with our practical experience we had. It was good approach and I liked it. Therefore I think I received more from the book then I would have learned alone just by normal reading from start to end.
I will do my best to do a review of the Clean Code for you. I am going to start with a little motivation, then what I learned and used after one year and then a summary of pros and contras.
“I am a good programmer, I can do my new task fast, it is normal that code is messy…”
I sometimes deal with such statements. They are true or false based on the perspective. If you were a typical startup developer, then I would say yes. There is no high demand for a good design. Time and a number of implemented prototypes is what it counts. But if we took a look for example on a complex middleware system of a large business, then I think that such statement as in the headline would be wrong. Let’s focus on these large enterprise systems. Based on my experience, some programmers are not able to foresee or are not capable of long-term thinking. Unfortunately I already spent too much time analyzing badly written code some else’s. Because it was written without thinking that another programmer would later need to work on it, to understand it. The original target was to finish the task as soon as possible (and unfortunately without seeing the consequences). Of course the latter task is expected to be finished as soon as possible too. But now it is different, now it is more difficult.
Let’s admit it. The most of the development projects are about team work. If we want to consider ourselves to be good team players, we should write our code with respect to our valuable colleagues. To make them their job as easy as possible. To keep in mind that they will once most likely read our code. They will have to understand it, change it and refactor it.
Now from the management perspective. I understand how deadlines are important. However I think it is beneficial to support developers and let them write clean code. The subsequent software support costs will be much lower. A good manager should take care not only for the next approaching deadline, but he should always plan the project in a way, that there is a space left for improvements and clean code. In other words I think that a good manager must treat deadlines and long-term project sustainability equally to produce the best value for their company. What I mean – the first barely working solution is not the same as the working solution that is already easy to understand and easy to change.
Clean Code principles as I remember them after one year
The book contains quite a lot of chunks of the code. The reader may train his skills on those. I read this book about one year ago, so I do not remember everything exactly, but I’ll try to summarize what I remembered and applied in my projects. I am going to structure the list of the principles as I remember them and order them depending on how often I use with them.
Every class or method should have one clear responsibility. If I find a class or method that it deals with more responsiblities, then I’ll separate the responsibilties by creating a new class or a method.
Usually when the class or method is too long it is also an issue. In such long implementations we can usually identify more responsibilities and find out which responsibilities should be separated. It also means that the operations should not have side effects.
Distinctive class and method names
This rule applies more often for method names. Simply make their name as distinctive as possible. Better a long distinctive name than a shorter one, which is ambiguous or unclear. Also a long descriptive method name is better than a short name and a piece of Javadoc.
Understandable method calls
Very common problem. It is very difficult to read and understand method calls with too much parameters. I try to use one argument, two in fewer cases and three only exceptionally. It really helps. Another thing to mention is that it is better to write methods that do not need to accept arguments as null (what is this null?!), true/false (what is actually true or false?!), etc.
Keep classes small, single purpose and unit testable
Small classes are not just about lines of code. Also the amount class fields and method needs to be reasonable.
Testability is very important. Always design with testability in mind. Write unit tests for your classes. Then you may freely refactor without fear that you’ll break something. Such fear is very common and many programmers rather stay out of trouble, e.g. they don’t dare to change the code they do not understand. I think this is bad habit and also a sign of badly written code. Another common problem is that the unit test is trying to test more than is expected from the tested class. In such a case, the test needs to be moved to the appropriate place.
Pros and contras
I took a look on the book. Of course the book contains more topics, like concurrency, error handling, etc. It contains a lot of practical examples to force you to think. I did not cover everything. Let’s summarize pros and contras.
- A lot of useful information for your developer career. Senior developers are basically those, who are able to work independently, but I believe that knowledge of such book belongs to their knowledge as well.
- Experience from the experts in the field.
- Good structure.
- Clear argumentation.
- Practical examples.
- Examples are sometimes too long and it’s quite difficult to focus on them.
- Our reading group in my job agreed, that not everything can be easily applied. Some of the rule recommendations seemed unnecessarily strict to us.
This book is about opinions, how the good code should look like. It carries knowledge and experience of the author and his friends. You may not agree with him, but it is still definitely worth reading. At least you can confront your development style with the one offered by the author.
I liked this book. It helped me to improve my Java coding abilities. I am sure it helped our team as well. I would recommend it to every Java developer, who works in a team. As a bonus I would recommend to organize a reading group in your company as we did. It forces you to read the book regularly. The discussions afterwards with my colleagues were very beneficial.
If you have something to add or you disagree, feel free to leave a comment!