Architecture & design · Book notes
The Practice of Programming and the style fight nobody should win
Kernighan and Pike said to pick one style and stop arguing, and the formatters took that literally.
If you get a pull request back with 30 comments and most of them are about where the brace goes, or that some lines are more than 80 characters, or whatever, it’s just a waste of everyone’s time. Kernighan and Pike tried to put an end to this nonsense in 1999 with The Practice of Programming, but I think the “preferably ours” is the most honest part of the sentence “Pick one style, preferably ours, use it consistently, and don’t waste time arguing.”
People took this advice literally. gofmt is one style, built into the Go toolchain. One of the Go proverbs from Rob Pike is “Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite.”
If somebody just makes an opinionated choice, throws it into the build pipelines and set expectations, all of a sudden you’re just thinking about the code you’re writing and you’re not fighting over 80 columns versus 120 columns.
Arguing about style is the cheapest fight to lose, and I’d rather lose it to a tool. It also changes who has to deliver the bad news in the review.
The linter is fair, the linter is dispassionate, and the linter is not a human. And I think the linter is the perfect tool for nitpicking style.
The linter tells you to add a brace and nobody cares.. the reviewer can just focus on the code.
The other half of the advice in the book (which people often don’t mention) is that when working on a program written by someone else, you should maintain the style that’s already there.
Most of the people in this industry are not dumb. And so anything that was built a certain way often had a good reason for being built that way, even if that reason was we didn’t have enough time or we didn’t have enough money.
Respecting the existing style is a soft skill masquerading as a hard skill. If you reformat someone else’s codebase in your first week, you burn through credibility you’ll need to make a change that actually matters.
The book’s reader is the next programmer. Increasingly, the next reader is a coding agent that doesn’t care where you put your braces. Is the formatter the last surviving style guide, or does consistency matter more now that the agent mimics the patterns around it?