Writing Code for the Next Person

Coding Style

Selecting a Style

If there is one topic that can start a debate more than any other in a development team, it is coding style. Most teams have a preference, and some companies even publicly document their coding style guides for the world to see. I applaud the companies that do publish theirs, as it allows for teams to learn from each other.

Among some of the well-known style guides are the following. This isn't intended to be an exhaustive list, but they represent the ones I encounter most frequently in my professional work.

Which style a team chooses to use doesn't matter so much (though I have my preferences I will share below), but what is important for productivity is to agree on a style and use it consistently. Doing so can improve productivity, as the layout becomes familiar to each person on the team.

My Personal Preference

My personal preference — and also largely adopted by Microsoft — is the Allman style. It wasn't always like that, though. When I started out my career, I wrote C code using the K&R style. As time passed — and perhaps influenced by Microsoft and other companies writing Allman style — I grew rather fond of it.

With K&R (which is also substantially adopted by Rust), the opening braces appear at the end of lines. The negative side effect of that is that one wastes time locating matching braces. While some code editors can help highlight matching braces, having them align vertically makes it much faster to see code blocks. Plus, the additional white space makes it easier to read. This gets into accessibility considerations I'll discuss next.

In addition to brace placement, I've adopted the style of PascalCase for function names; snake_case for formal function parameters, local variables, and class member variables; and Upper_Snake_Case for class member constants or global constants. For indentation, I use four spaces.