Programmer Musings

Review of The Art of Readable Code

The Art of Readable Code
Dustin Boswell and Trevor Foucher
O'Reilly Media, Inc., 2012

When I saw this book, it seemed like a great idea. I've spent my entire career with legacy codebases, trying to make them better. A book that covers ways to make code more readable, and therefore, more maintainable is a wonderful resource.

The book starts with a discussion of small changes that you can make to improve code: naming, aesthetics, and commenting. The authors do a good job of covering what makes a good name and how careful naming can really help the readability of the code. They touch on the lengths of names and manage not to make the mistake of so many by mandating that long names are always best. In the section on aesthetics, they discuss how the look of the code can help with understanding, similar structure conveying similar intent. They even spend a lot of time on making comments pull their own weight and what makes a good comment.

The second section covers structuring control flow and expressions for readability. In the process, they touch on but don't really go into the importance of idioms for making code more recognizable even when you can't read it in depth. Despite that lack, they make a good case for standardizing sections of code into similar forms and simplifying loops and conditionals. Since complicated code structure is hard to read, simplifying these structures improves readability.

The third section moves out of small-scale changes and begins talking about larger restructuring to improve code. In this section, they finally mention some standard forms of refactoring. They also advocate thinking a bit more about what you are trying to accomplish before writing the code. They do not push for full scale BDUF, but instead focus on thinking through subroutines and chunks of code to make certain that you understand what you are doing before writing a bunch of code.

The final major part of the book covers testing and one large case study showing how to apply what you've learned in the book. In the case study, they start with a sub-optimal solution to a problem and make it better and faster while improving its readability. They come very close to implying that the readability is the cause of the performance increase without quite going there.

Overall, I found the book to be quite readable. They did not go as far as I would have in a few areas. They used several programming languages for their examples. For each of those languages, they focused on how to use the idioms of the language to make their point. That handling of languages makes one of my disappointments with the book stand out. In the section on control flow, they make the statement:

Many respected programming languages, as well as Perl, have a do { expression } while (condition) loop.

The only mention of any language that they were not using in their examples is an snarky reference to Perl. I understand that many people really don't like the language, but the random sniping does get old. I was especially amused when they praised the newer languages on their list for features that have been in Perl for decades. That suggests that they may never have programmed in the one language they bashed.

Despite that one piece of snark, I would recommend this book to a junior programmer trying to learn to code. For intermediate or senior level programmers, this book could be a start, but I would expect to go further into idioms, choice of audience, code smells, and other issues relating to high quality code.