I had heard about the book Clean Code by Robert Martin for a while before I finally read it. I was a PM / SM / PO blend at the time but I was glad that finally someone was writing something that people were actually using to get a bit better at coding. I first read it at the end of last year and really enjoyed it. When I started coding full time again this year I reread it. I wish I had read it 13 years ago. Though possible I wouldn’t have been mature enough to get it. But it would have made several things a little simpler.
A couple of things were Ah-Ha! moments for me.
- Placement of methods in relationship to other methods – where to place code in a class so it is easy to find and readable.
- Error handling is a separate concern – remove it from the main flow of the code and the code gets far more readable.
- Code is read more than it is written. Make it readable. And that can take several passes. You need to know how to refactor safely and effectively.
- Breaking up the code into small chunks is exactly what we do in Scrum with Stories.
- Clean Code isn’t necessarily good code. This isn’t a book about design. In some ways it is the prerequisites to enable you to better see the design that is emerging so that your design can become good. Then your clean code may be awesome code.
The thing that makes Clean Code beautiful is that it gives you simple rules or ideas that when you read them you go, hmmm… interesting – I hadn’t looked at it that way, but it could work. And it makes sense. So then you try them.
I have never had anyone outlining clear patterns for how to actually layout code before. Perhaps I’ve missed the books or perhaps I didn’t find them accessible or perhaps I wasn’t in the mind space to be looking for them. Developers are good at reinventing the wheel. Everyone comes up with coding standards – but no one places the business value and understanding of why those coding standards are what they are. Too often they feel like arbitrary rules. No coding standard I’ve seen before has expressed the idea of readability – like a newspaper – and the flow of where you should try and think about placing the methods that another method calls. No coding standard I’ve seen before has captured the idea of how you read the code as being important. Most coding standards have “name your variable like this” or “name your method like this” types of rules – but none of them roll these ideas up to the class as a whole. They all look at the micro level – at the single line of code where you name your variable tszEndUserName. Not that this makes them bad. Coding standards are useful in helping to unify the way people code on a project which is useful. But too often it doesn’t work as well as one might envision. My experience is things without the why usually don’t work as well as one might envision.
Admittedly a lot of the ideas that are suggested are made much easier by today’s IDEs helping us and also due to the style that Uncle Bob and all the other authors in Clean Code suggest. If you keep the entire class file under 100 lines it is very easy to find out anything that you want in that class.
Error handling as a separation of concerns was a particular light bulb moment for me. I started my coding career working on operating system code in C++/C. There were no concepts of exception handling at the time. Everything we returned had to have an error code. And you could never ever crash. This has influenced my view of how I write code and have expected others to write code. Paranoid and defensively. In business applications this isn’t always useful. Extracting the concern of error handling and using exceptions effectively makes the code clearer. This is a Good Thing. Combining that with using the Null object pattern could make for some great goodness.
Write Once Read Many
Most people don’t think about this. But when it is pointed out, it is really obvious. Developers read the code more than they write it. So spending the time to make it able to be understood and work well makes a lot of sense. If you need to spend a lot of time working it out later, that is costly – and time not spent doing other things – like adding new features.
This does imply however that you have tests to safely refactor the underlying workings of the design several times. Refactoring without those tests will make the process far more painful – and less likely to be as successful.
Small Methods and Classes
One of the areas I’ve heard people object relatively strongly to is method size. The common argument is that they can understand the whole method by looking at all 30+ lines of it in one go instead of having to jump to multiple different places in order to read all the code. I understand this argument and empathise with it a bit.
I’ve heard similar arguments made for why small story size isn’t effective. It is impossible to implement or understand a small story. It needs to get larger in order to do it right / get the full picture / etc. But in Scrum and other agile techniques the value of breaking things smaller has been proven to be effective.
Small methods and small classes and highly descriptive naming all add up to reducing the batch size. When I want to understand something – the smaller the thing is that I need to understand and fix the better. Simple is good.
But simple is hard. And one underlying reason why I would need to look in each of those methods is that I can’t necessarily trust that they will do exactly what they say they do. And that is a root cause. Not the act of breaking them down. A code base needs to learn to trust that a method does what is says it will do and no more and then small methods will become more trusted as you won’t need to delve into every single one in order to understand why something isn’t working as is expected.
Design and Clean Code
Clean Code isn’t (much) about design. It is largely working in the micro level of your code to make it cleaner and more beautiful. There is unfortunately a new tendency of software developers to read this book (or get told about it) and then talk about how they are writing clean code. Too often that involves grabbing some of the ideas portrayed and ignoring many others. And then using the fact that they are writing clean code to imply that they are writing good code. I’ve worked in organisations where clean code meant the code I write – which didn’t include tests.
Robert Martin has done a good thing in writing this book. What people refer to now as clean code may not be quite what he intended. Just like Scrum – there will be many ways of viewing clean code – and not all of them will be highly effective and give the true promises of what was originally intended by the author. What probably was intended was getting people talking about the idea of focusing on code quality. And that is a Good Thing.
Cleaning my code
I’ve been enjoying using these ideas while practicing coding katas and learning TDD. I’ve been trying to clean up my production code using continuous refactoring. It has been a great experience for me to be completely in control of my code using TDD. And trying out these ideas has increased my understanding and I believe the quality of the code I write now. Of course I can always get better and I look forward to doing so. I particularly look forward to reading the Principles, Patterns and Practices book as well as watching the Clean Coders videos to push my coding a little bit further.
Clean code is a small stepping stone to writing great code. It is wonderful that someone has written these ideas down instead of just the macro design ones. It is particularly great that it is so readable and presented in such an accessible way. Thanks Uncle Bob!