Lots of software organizations concerned with the quality of their work believe that applying a uniform coding standard is an important and beneficial part of their quality strategy. I agree with that belief.
Not everyone likes being required to follow a coding standard. I've been involved in at least two development groups where a coding standard was drafted and adopted, only to be abandoned later (or immediately!) due to general indifference and the "we're too busy" excuse. Other groups never bothered with a standard at all.
The results were predictable: code that is poorly commented; sporting a variety of naming conventions, indentation and paragraphing styles; and difficult for new developers to learn, making maintenance timelines much longer than they ought to be.
Here I'm beginning to collect some of the retorts one might hear from a "cowboy programmer" who doesn't want to be fenced in by a coding standard.
I can write code faster and better if I do it my own way.
A programmer worth his salary should be able to write code fast enough and well enough even if he has to follow a coding standard that differs from his own preferences. If not, then perhaps he's in the wrong job. Software spends most of its lifetime in maintenance, not development. What really matters, then, is how long it takes the next programmer to understand the code, not how long it takes the cowboy to write it. And that's where a coding standard is meant to help.
Chuck Taylor --