Two stories regarding coding standards.

~

At my old day job (sprawling planet-eating Java), the codebase had gone through many hands over the course of ten or so years. The "age" of some code or feature could usually be determined by looking at how it was written: newest code used the Java foreach construct, older code (usually by one particular developer) used explicit for constructs, and the oldest code reimplemented (poorly) collection classes without generics.

Additionally, the fist (coding style) of each person who'd worked on a section became apparent: my own code tended to have a large number of anonymous inner classes and monkey closures, as well as somewhat heavy use of interface and abstract classes. Another coder liked static factory methods a lot, as well as very shallow inheritance hierarchies (in order to make debugging simpler). The oldest code was the poster child for 90s Java: EnterpriseFactoryProxyFacadeAdaptorSingletonProviders, overly wordy code to accomplish simple tasks, etc.

It was interesting to open a file or function to implement a feature or bugfix and then twitch when you realized that it was from one of the more...time-pressed...veteran... developers. By contrast, opening code in a particular style (indenting, commenting, etc.) I recognized as my own or another coworker brought relief.

~

At the same time I was working on this, I worked on a large library with some friends doing gamedev. We agreed on a coding standard, had some rather arcane arguments, and ultimately settled on something that drew heavy inspiration from Insomniac's coding guide--not exactly alike, but we at least had an opinion on nearly everything they cover.

Whenever working on that code, I have a very different feeling. Despite the fact that we're all working on it at the same time, and despite the fact that we all have some remnants of our fists, the codebase still feels fairly uniform and like home.

Variable naming is basically the same, choice of verbs and methods is the same, indentation is nearly the same (as are the cases where liberties are taken), commenting is consistent where it matters (fists show through in individual writing styles, but documentation for interfaces and function signatures is standardized), and overall there is a high amount of consistency.

Even deeper, the amount of cleverness is roughly equivalent throughout the code--as we use C++, this cannot be undersold. We've come to a consensus on when and how to use templates, and in what ways, and when to use defines, and how we treat inheritance and interfaces and abstractions. We have house rules on how things should behave; in a language where you can overload and redefine operators, restraint is important.

~

Overall, having a common coding standard--and moreover, one that everyone has closely examined and discussed and agreed on--really helps decrease cognitive load. It gives better "faith" in your codebase, and reduces the annoyance of working on somebody else's code. It reduces the impedance mismatch of abstractions as they work together, and helps to reassure you when its three in the goddamn morning and why the christ am i getting these compiler warnings sheezus didnt anybody read through this before committing argh at least we have unit tests.

It's also something a lot of people seem to dismiss as bike-shedding, and sometimes it can seem like that. It's at least worth considering, especially if you work with people you care about--coding on a team should be like a relationship, and any successful relationship involves developing a common background and shorthand for communicating.