Years ago when the coding standards book first appeared at the place I was working at the time, along with the obligatory corporate comment that this was indeed the “magic bullet” to fix all our problems, I couldn’t bear the pain of a “code review” that ended up turning into a “coding standards review”. A one-hour meeting rapidly turned into a 55-minute discussion over the position of a semicolon and perhaps 5 minutes, if you were lucky, actually looking at what the code did. The reviewee usually considered any coding standard observation as a personal affront. The upshot of it all was usually the review had a negative effect on motivation and morale.

I’ve changed my mind lately, since we now have effective, virtually zero-cost mechanisms to follow the coding standards (such as better formatting in the IDE, and automatable tools such as Checkstyle to produce the reports). People don’t take offense if their ‘violations’ are reported by a machine, and code review time is never taken up with style issues if you can just take it offline and go view the reports in your own time. I’ve found that if the quick view of the reports identifies a ’sloppy’ area, then usually that area contains correspondingly more ‘technical’ problems at well. I am not sure if there has been any recent study to prove this correlation, but it’s a gut feeling that’s grown stronger lately - strong enough that I would happily recommend to a beginning coder to use the automated tools and reports to identify those areas needing attention. The tools allow the coder to focus on more important things; the results seem to indicate where the coder didn’t focus at all.

If coding standards have to exist, they should be called coding guidelines and should be represent the acquired wisdom of the group. This is the type of thing you might want to write guidelines on:
* Aviod global variables if at all possible. Exceptions may be made for configuration constants which should always be kept together at the top of the file in one block.
* Try to keep the length of a function to within less than 50 lines. If it’s more than this, refactor into subroutines.
* If you’re writing in a language which doesn’t enforce private methods (like perl) prefix the internal method names with an underscode. That way it’ll be obvious if you’re calling an internal method from another class when you shouldn’t be.
These are just some examples I’ve used before. And the fewer rules you have, the more effective each one is.

How do you format your code? Do you put the “{” on the same line as the “if (…)” or on the next line? Do you write “x=3;” or “x = 3;”? Do you write “if (…) return;” or “if (…) { return; }”? Do you write “this.value” when you access an instance variable or just “value”?

All these things belong in a coding standard. Not because they help writing good code, but to have a common style in team team. This is important if you don’t believe in “code ownership”, but have a team where the code of every module should be known and perhaps even worked on by more than one person, and where people sometimes have to fix bugs in modules they did not write themselves.

A common style helps me to read code that I have not written myself more easy. I can focus on understanding the code instead of “re-formatting” it inside my mind. I am glad we do have a coding standard.