- There's a tendency for people to conflate personal preference with empirically-proven benefit.
- There's a tendency for the 'tidy-desk-tidy-mind' fetishists to brandish coding standards as a way of achieving the requisite level of code conformity - "THERE MUST BE NO INCONSISTENCY IN THE CODEBASE!". I find this type of software engineer ever so slightly tedious, to be honest. People vary in coding style like they vary in writing style, and whilst every effort should be made to conform to a common style where it matters, it is simply not necessary to constrain every little detail.
- On the other hand, coding standards can bring a desirable level of uniformity that allows people to move over the code base without jarring inconsistencies.
- They can also be used to explicitly rule out certain undesirable traits or bad habits.
Where things get trickiest, I find, is when you've agreed all the obvious points, and are debating what you might think are the more marginal details. Everyone generally agrees what the horrendous no-no's are (for instance, in our team we ban the use of complex prefixes on variables, other than a m_ on member variables - there's simply no need for it in a type safe language), they're easy to spot, everyone acknowledges they shouldn't be done, and there's usually no argument about explicitly dealing with them in the standards doc.
When you get to something slightly less obvious, say, arguing the finer points of parameter naming convention, or whether or not you should ban the use of #regions, people start grabbing their pitchforks and preparing for war.
It's at this point that the worst aspects of programmers as personality types usually emerge - detail obsessed, a certain level of anal retentiveness, an inability to communicate differences without needlessly inflaming others. These characteristics are stereotypes for a reason - software engineering surely has a higher-than-normal proportion of borderline Aspergers sufferers.
