Collective Wisdom from the Experts 27
Expressive layout
We’ve all learned to take the time to find the right names so that our code
expresses as clearly as possible what it does, rather than just listing the
steps—right? The code’s layout is part of this expressiveness, too. A first cut
is to have the team agree on an automatic formatter for the basics, and then
I might make adjustments by hand while I’m coding. Unless there’s active
dissension, a team will quickly converge on a common “hand-finished”
style. A formatter cannot understand my intentions (I should know, I once
wrote one), and it’s more important to me that the line breaks and groupings
reflect the intention of the code, not just the syntax of the language. (Kevin
McGuire freed me from my bondage to automatic code formatters.)
Compact format
The more I can get on a screen, the more I can see without breaking con-
text by scrolling or switching files, which means I can keep less state in my
head. Long procedure comments and lots of whitespace made sense for
eight-character names and line printers, but now I live in an IDE that does
syntax coloring and cross linking. Pixels are my limiting factor, so I want
every one to contribute to my understanding of the code. I want the layout
to help me understand the code, but no more than that.
A nonprogrammer friend once remarked that code looks like poetry. I get
that feeling from really good code—that everything in the text has a purpose,
and that it’s there to help me understand the idea. Unfortunately, writing code
doesn’t have the same romantic image as writing poetry.