The thing about defining a coding style standard is that there is no objective means by which to judge one style as “better” or “more-right” than another.

I can think of several objective criteria for judging coding standards practices off the top of my head:

• Does the practice allow more code to be fit on the screen/page at one time (braces on the same line)
• Does the code use white space to emphasize when things should be separate (spaces after commas)
• Can the code written to the standard be viewed in multiple media and multiple editors (spaces not tabs, limited line lengths)
• Does the practice conserve keystrokes (tabs not spaces, no spaces after commas )
• Does the practice facilitate copy and pasting (single statement of code per line)
• Does the practice require extra work to maintain the code (java docs and formatted comment headers are harder to edit beceause of the prefix, aligning equals signs, etc)

Obviously some practices can cause conflicts between criteria. In this case, readability should triumph over key strokes. Practices that require require editing unrelated lines during maintenance should be avoided.

One thing that I have found about refactoring is that no code smell is too small to fix. Having your code in refactored normal form and the process of getting it there by performing small, seemingly unimportant refactorings can reveal the major refactorings that are really worth it. Sometimes the major changes that need to be made are obscured by minor code smells.

Coding styles perform a similar function. Having your code in a “normalized” form frees the mind to consider other aspects of the code. Poorly or inconsistently styled code can obscure refactorings. With a good coding standard, the benefits outweigh having to re-train yourself out of a few habits. I agree with Paul’s conclusion here.

Fortunately, the PEAR standards has made the right decisions regarding these criteria with a couple of minor exceptions and many omissions.

The exceptions as I see them:

• aligning equal signs should be discouraged.
• The braces policy for functions should match that of control structures
• embedding inheritance heirarchy into the class name is bad

UPDATE: Looks I am not the only one who thinks bad style is a bad smell