I recently picked up The Art of Readable Code by Dustin Boswell and Trevor Foucher. I was looking for a light-hearted dive into good coding practices and definitely got what I wanted. The authors did a great job of keeping the book informative but also easy to follow, and it makes for perfect bedtime reading material.
The core concept behind the book is that there are certain coding patterns you can follow to refactor your code. Because this is not a design book, the authors don’t really spend that much time on large-scale refactoring; instead, they’re looking at lines of code and trying to make incremental improvements along the lines of:
- Avoid do loops and convert them to while or for loops—keep developers from having to scan up and down to understand the flow of logic
- Use good names for variables, where a good name is both descriptive and neither too long nor too short
- Make sure comments are necessary and meaningful. “The code documents itself” is a joke excuse for not having comments, but comments for the sake of comments aren’t good either.
None of their topics are earth-shattering, but each chapter comes with stories, examples of bad and good code, and an explanation of how to get from bad code to good code. Following the authors’ advice may not lead to a better code base overnight, but given time, a team which dedicates itself to refactoring on the small can make big changes.
The final two chapters are fantastic. In the penultimate chapter, the authors walk through creating unit tests and show some of the pitfalls that exist, like unnecessarily complex unit tests and code repetition within unit tests. They then walk through how to solve these problems and make your test code much easier to understand and write, using things like helper methods to encapsulate repeated code. This leads up to the final chapter, in which the authors design and develop a relatively small class which starts as a way of tracking bytes transmitted per minute and per hour, but then evolves into a more generic solution for units per time period. You might think that the end code would be a lot more complex, but it turns out to be just as simple as the initial prototype code.
This book is a great companion to Martin Fowler’s book Refactoring. Refactoring hits hard and this book helps solidify the good ideas behind refactoring code.
Overall, I very highly recommend the book and will probably read it again someday (which is pretty rare for me).