I encounter a lot of unreadable code because I work through a lot of code I download from the Internet for learning purposes and rework code from failed projects. So, it was with great interest that I opened The Art of Readable Code by Dustin Boswell and Trevor Foucher. After reading this relatively short book, I’m convinced it should be picked up as a college text. If developers would follow even half the advice in the book, many of the truly weird errors in code today would simply disappear because developers wouldn’t end up overwriting the good parts of other developer’s code due to a lack of understanding it.
The authors rely heavily on humor to make good points about writing code that is easy to read by others. The cartoons are engaging and fun. I wouldn’t necessarily call them funny—some of the jokes are tongue-in-cheek and others are a bit dry, but they’re all in good taste and make important points. As for the good points in the book, I don’t think I’ve ever seen anyone suggest that a developer actually turn to a thesaurus to find a better name for a variable, but the authors make this point on page 9. The point is made in a humorous way—not as a command as I’ve seen some authors do. I did laugh relatively often. For example, “The Ultra Hard Metal Nail Smashing Rod” reference on page 13 gave me quite a laugh. You’ll need to see the reference for yourself to understand it.
You’ll want to pay attention to the frequent Advice blocks in this book. In fact, if you’re short on time, skim the book looking for these blocks (and the Key Idea blocks I describe in the next paragraph) and you’ll improve your coding technique significantly. Some of the advice is obvious to a veteran programmer. For example, on page 25 the authors advise putting max_ or min_ in front of programming elements that describe some sort of limit. (If only novice programmers would follow that simple advice.) I only wish that the Advice blocks appeared with greater regularity later in the book. I would have welcomed advice from the authors on some of the more complex topics.
The Key Idea block is another useful addition in the book. For example, on page 122 you find the authors advocating that you create code that only performs one task at a time. Even though this idea seems quite obvious, you’ve probably seen code that is trying to do too much and ends up not doing anything well. The authors back up their Key Ideas with good coding examples (some relatively complex). Unlike the Advice block, the Key Idea block does appear with good consistency throughout the book and the authors have used it quite well.
The section on Eliminating Variables that starts on page 94 was especially useful for me. I often create intermediate variables while writing an application to aid in debugging it. The authors provide techniques that greatly simplify code without making it much more difficult to debug later. Even so, sometimes you really do need that intermediate variable for a while. The point is that you should simplify your code as it nears production to reduce complexity, provide fewer failure points, and improve performance.
As with any book you buy, this one does forward the author’s agenda. If you follow all of the advice in the book, your programming style will closely reflect the style that the authors use. Anyone who has written a lot of code knows that there are many perfectly acceptable styles of coding. The point is to make your code readable so that someone coming behind you can pick up on your style and quickly discover how your code works. For example, I still prefer to use a form of Hungarian Notation for my applications. Because I apply the notation consistently, my code is readable, but many developers feel that the notation is outmoded. Whether you use Hungarian Notation or not is not the point, the readability of your code is. The authors express their view of Hungarian Notation on page 17—as with many other parts of this book, they take a firm middle ground approach that should serve the reader well.
There is a lot to like about this book. As I said at the beginning of the review, colleges would do well to incorporate it into their curriculum. The authors do press their style of coding strongly at times, but I imagine that if I were writing this book I would do the same things, so I can hardly fault them on this point. The content is a bit simplistic for the veteran programmer at the beginning, so you might want to start around Chapter 7. Overall, I think this is a good and much needed book.