A coding standards document is useful. It's most useful when it's short enough that anybody can remember the whole thing without too much trouble and when it doesn't cause anybody too much pain.
How you choose to indent code in your organization, or capitalize names, or implement your loops, or comment your code doesn't matter all that much; the helpful part is getting everybody to write code that looks about the same as everybody else's.
- It avoids having to spend a minute recalibrating your expectation of where braces should be and such every single time you look at someone else's code.
- It avoids having several different styles of code all in the same file.
- Perhaps most importantly, having a written standard avoids arguments about coding practices during code reviews.
Again, what the standards are doesn't matter as much as having some sort of simple, straightforward standard. So, put all your developers in a room and let them argue about what the standards should be. This meeting could go on indefinitely, so the rules are:
- Anything not decided by the end of the meeting will be decided by the manager.
- The meeting will end after two hours, or when someone starts shouting or crying, whichever comes first.
- The entire standard will fit (in reasonable type size!) on a sheet or two of paper, double-sided only if absolutely necessary.
Consider adopting somebody | else's | standards either as a starting point for your own coding standards meeting, or as a way of avoiding the meeting entirely.
Once agreed upon, developers should be able to (and should be expected to) police themselves. Occasional deviation from the standard shouldn't be a big deal (and might even be justifiable), but curmudgeonly refusal to abandon some favorite personal style in favor of the standard should result in immediate relocation to the office with the leaky water pipes, or whatever.
Demian Brecht points to lint tools. These are a perfect complement to a coding standards document. It's merely good to stick to coding style standards; it's important to stick to coding standards that relate to dangerous practices. Nobody other than the author is going to check that every line of code meets the standard for style, but you should certainly consider building a lint tool into your team's workflow to automatically catch likely bugs. In addition, the tool itself can codify the accepted practices so that you don't have to list them all individually in the coding standards; just specify the tool's configuration.
Note: The "coding standards" idea is not unique to programming. "Coding standards" are used in many fields, sometimes within an organization, more often across an entire industry or profession. Some examples:
In each case (and many others) a competent practitioner could easily understand "code" that doesn't meet the expected standard. Why do so many industries persist in writing detailed requirements for documents that don't even need to be parsed by a compiler? Because style matters. Presenting information in a standard style lets the reader focus entirely on content, makes reading faster and aids understanding, and reduces errors.
varinstead of the fully qualified type name.