I’ve been thinking about coding standards again recently. For me a coding standard should definitely be more than just about formatting and naming conventions. That stuff matters, but it’s also relatively trivial to agree upon and then stick to.
Essentially I think the standard should clarify “the way we do things here” (wherever “here” might be for you).
The objective should be twofold:
-
to educate everyone in your team, and teach them about good techniques and common pitfalls
-
when there is more than one way to do something, to clarify which way to choose, so that code is designed in a consistent way and a programmer working in any area can intuitively work out how another area is likely to work, where to look when there are problems, and how to approach extending an area or adding a new one
My suspicion is that the exact choices that one makes when designing and implementing something often aren’t the most important thing. In fact, too much choice can (and often does) paralyse me. Obviously avoiding really stupid decisions is a requirement, but after that, there may well be a number of adequate solutions to a problem.
The important thing when working in a team is consistency. If you’re consistent, and agile, you can move fast. If everyone can understand the designs and the code, it will always be easy to revisit the occasional choice that turns out later to be wrong.
To achieve that, you need good standards, and you need good discipline. People need to buy into the idea of a standard, and try their best to stick to it, even the bits that they might not like.
In my experience, once you let go and just follow the standard, it’s amazing how quickly a lot of those disagreements seem to become trivial and you are left free to concentrate on the important stuff.
That doesn’t mean that designing a standard for a team is trivial. It’s pretty tricky, but very important. Once it’s done though, just go with it.