So, Rocky reflected on coding standards, and ended up here:
This was the point where I had my first professional developer epiphany. Yes, it is truly painful to adapt to the idea of living within strict coding and style guidelines. But the alternative is so much worse!
Ever since that experience I insist on consistency of coding standards and styles within each project (or enterprise) where I work. And even if I think some choices (like 2 spaces after each tab) are really, really, really stupid, I'll use and vehemently support that choice.
Um, no.
There will always be exceptions, since such is life, but otherwise, on any codebase of any significance, with any number of contributors over any number of years, the need to enforce coding standards or styles is wasted effort, and counter productive.
I would actually extend this point even more radically. In various projects I’ve worked on, there have been (to use what should be a recognizable example) many different data access ‘methods’: stored procedures, inline SQL, ADO.NET, LINQ to SQL, Entity Framework, etc.
On one level, this is insane, of course. However, it is also perfectly manageable. If you know anything about .NET and have been programming for even more than a few years, you can program using all of these, and can move back and forth between them with little effort.
That is to say, on any code base that has existed over any period of time, different ways of programming have been used by different developers over time. To the extent that you do actually follow a pattern, that’s great (so, for instance, even though I prefer something like Entity Framework, if the module I’m working on uses stored procedures, I’ll default to that), but thinking that enforcing a style (like 2 spaces after each tab) is a good idea is just stupid.
You might as well enforce the types of socks your development team wears.