My Coding Standards

Wednesday, November 27, 2002

Sometimes it's like I'm a war veteran in my head. I'll be going along, minding my own business, when *bang*! out of nowhere, a flashback from my days as the director of a software organization hits me right between the eyes. When it happened today, I thought it would be therapeutic to talk about it instead of trying to bury it when these "episodes" intruded on my normal life.

The nice thing about setting up your own software organization is that you get to set your own rules, and this time "do it right." I had always planned on getting my engineers together one day and coming up with a common coding standards document, just like every software organization had, but in the interim, we started with this one:

1. All code will use spaces instead of tabs.
2. All new code in an existing file will match the existing style.

Rule #1 nicely handles the case where different editors expand tabs to different spaces, causing code that was easy to read when it was written to go all crazy. Rule #2 says not to waste time reformatting existing code into your own style, but to mimic the coding style that was used by the original author. Rule #2 had the unexpected side effect of helping developers get into each others' heads, which helped transfer knowledge between us. I personally learned a bunch of cool tricks by fixing bugs in files in the style of the original author.

After a few attempts at adding other, more traditional rules to this short list, like where the braces go and how to name variables, we couldn't find anything that was worth ruining the simplicity of our two-rule coding standards with, so that's what I've used ever since. One other benefit of this simple set of coding standards was that it left us all kinds of time to debate the merits of various text editors, which is an argument that won't be solved until just after the Christianity vs. Judaism debate is ended...

Discuss