Very Short Coding Standard
I’ve read any number of coding standards. They’re usually long, hard to imagine any developer memorizing them, and not automatically testable. So I was pleased to see Gerard Holzmann’s attempt at something much shorter, in the June 2006 issue of Computer Magazine: The Power of 10: Rules for Developing Safety-Critical Code.
Holzmann is the lead technologist at JPL’s Laboratory for Reliable Software, so his proposal is definitely worth reading.
But coding standards always bring up arguments about what should or shouldn’t be included, as well as doubts about how, or how costly, to implement.
There’s even a question of whether, in a project that has neither code reviews nor static analysis, which to start first.
In that spirit, then, I offer this Very Short Coding Standard (VSCS) as a possible starting point for projects that need to “do something”. Just two items: one from the human side of things — requires code review to verify, and one based on a static analysis tool that everyone already has installed.
VSCS Rule #1: Use Meaningful Entity Names
VSCS Rule #2: Maintain Zero Compiler Warnings
My experience tells me that you get a big improvement in readability if you can come up with entity names that are obvious to reviewers as well as to yourself. For the power of compiler warnings, read Holzmann’s Rule 10.
Failure to meet either should break the build and be handled immediately by refactoring.
VSCS is short, but not as easy to deploy as it might seem.
If your organization thinks it should do much more, first get this working and then go further.