The book starts by talking about time until understanding, and how important that is for programmer productivity.Of course, you can’t even begin to start working with code until you understand it. The authors talk about just how important this is on a large development team where you have multiple people working on the same code at different times in the project. This is something I’ve been preaching for a while in my talks, and I’m glad that </cite>The Art of Readable Code follows the same reasoning.
The first few chapters go into specifics of naming and how naming can really help in the understanding of code. Little tidbits about how naming affects our understanding are included, as well as some of the questions around naming such as how long the name should be. The difference between a naming variables, functions, and Constance is discussed, along with some great examples of how to naming should meet developer expectations. For example, a method beginning with the word “get” this often assumed to be a fast getter method that doesn’t do much processing. However, if such a method ends up doing expensive processing and taking a long time, this gets confusing for developers. I had never thought about method naming in this way, but it makes a lot of sense.
The next few chapters focus on comments and when to use them. This is another topic that’s very close to my heart, as I generally feel like people don’t use comments enough. These chapters have some great examples of both bad and good comments. If we all just commented a little more, dealing with the world’s code would be much easier.
Other topics in the book include how to properly structure flow control statements for best understanding, how to properly break down large chunks of code, and how to re-factor for better readability. Most of the topics are accompanied by small comics that help to get the point across and give some welcome levity to the discussion.