97 Things Every Programmer Should Know

Chapter 13. Code Layout Matters

Steve Freeman

AN INFEASIBLE NUMBER OF YEARS AGO, I worked on a Cobol system where staff members weren’t allowed to change the indentation unless they already had a reason to change the code, because someone once broke something by letting a line slip into one of the special columns at the beginning of a line. This applied even if the layout was misleading, which it sometimes was, so we had to read the code very carefully because we couldn’t trust it. The policy must have cost a fortune in programmer drag.

There’s research suggesting that we all spend much more of our programming time navigating and reading code—finding where to make the change—than actually typing, so that’s what we want to optimize for. Here are three such optimizations:

Easy to scan

People are really good at visual pattern matching (a leftover trait from the time when we had to spot lions on the savannah), so I can help myself by making everything that isn’t directly relevant to the domain—all the “accidental complexity” that comes with most commercial languages—fade into the background by standardizing it. If code that behaves the same looks the same, then my perceptual system will help me pick out the differences. That’s why I also observe conventions about how to lay out the parts of a class within a compilation unit: constants, fields, public methods, private methods.

Expressive layout ...