

The goal of a coding standard isn't conformity ... it's correctness and maintainability. The first step is to hire people who care that the code they write is correct and maintainable. The second step is to write unit tests that cover the non-trivial portions of the code-base. The third step is to conduct peer code reviews - everyone can learn something and this especially helps junior programmers. The fourth step is to use tools to help you know which parts of the code base need attention.

My favorite tools (FindBugs, CheckStyle, PMD, JSlint, CppCheck, valgrind, vera++) can all be incorporated into a system I consider invaluable - Sonar (http://www.sonarsource.org/). If you add the SIG MM plugin (Software Improvement Group - Maintainability Model), you should have the tools you need to know how good your code really is.

Of course, whether you strictly follow every recommendation or not is up to you (there are false positives), but at least you have a basis for deciding what your "coding guidelines" should be.

It's not conformity or correctness it's maintainability though consistency...

I would much rather work under a standard that was the total opposite of what I am used to, that have none at all...

When I said "correctness", I meant that the software performed its intended function, not that the software correctly met a standard. Sorry for the confusion (I'm assuming you don't disagree with wanting software that's correct for this definition).
