Code style guides are for cooperation, not preferences
Nothing evokes strong opinions quite like coding style. Tabs-versus-spaces is a famous example. In most cases, there’s no meaningful difference between one style and another. People learn a particular style and then they come up with reasons why their style is The Right Way To Do It™. (Tabs-versus-spaces is one area where it does matter, as there are good arguments that tabs are more accessible.)
I don’t write a lot of code myself, but I definitely have a personal style that I’ve developed over time. I tend to favor the octothorpe for code comments in languages that give you choices because much of my early coding was in shell and Perl. I write one sentence per line in Markdown because fixed-width lines make for unintelligible diffs and semantic line breaks don’t work with my head for some reason.
But when I contribute to a project with a written style guide, I drop my preferences and follow the guide. Why would I do that, when my way is objectively superior? Because style is about consistency for cooperation, not about my personal preferences. When multiple people work on the same code (or prose, for that matter), inconsistent style can cause confusion. This only grows as more people join in. Worse, a mix of styles can lead to unexpected behavior in languages where, for example the indentation matters.
The GUAC project uses fixed-width lines in the Markdown files for the documentation site. This is enforced by a CI check. My first pull request to the repo failed that check, so I proposed getting rid of it to allow sentence-per-line content. The consensus was to keep it as-is because editors can be configured to hide that and it keeps people from making absurdly-long lines. I disagreed, but I decided to drop it because it was a case where being right was not more important than cooperating.
So if you’re leading a project, document your style. And if you’re joining a project, set your style preferences aside.
This post’s featured photo by Chris Ried on Unsplash
