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:
- All code will use spaces instead of tabs.
- 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
