When we started Ecora back in 1999, Daniel Sabin and I had little trouble keeping our code consistent in terms of style and formatting. We were able to follow all the conventions that we agreed upon (see below). A year or so down the road, with the development team at more than 10 people, keeping it all neat and clean was becoming a serious problem.
Asking developers to respect coding conventions that aren't theirs turned out to be a complete waste of time. Each developer had his own idea of the "best way" to do things, and, in all fairness, there was nothing fundamentally wrong with any of them. Choosing one style over another is just a matter of personal preference, with no real, quantifiable benefits. Despite that, I knew that if we were to allow each developer to write code in his own style, the code base will end up being a total mess, sloppy and unprofessional.
Initially, I politely asked everybody to try to adhere to the rules. Faced with total indifference towards the subject, I started emailing examples of bad code. Other than pissing a few people off, that didn't achieve much.
Well aware of the fact that in order to respect all
the conventions our developers had to remember quite
a few things, I figured that instead of bitching
incessantly about bad code I could slightly adapt
the style checking script I was using for my own
code so that it could be used to point out
non-conformant code. Developers would have to
remember fewer things, and I adapted the script
so that all they had to do was run another
make target (make
style-check), go through the errors and fix
them.
Well, that didn't work either. Most developers
didn't bother to run that damn make
target at all, and code would get committed to CVS
without having those problems fixed, just like
before. Some of the problems that the script
would've caught were really bad and had weird
effects at compile time - for instance, cutting and
pasting header preambles without changing the name
of the header inclusion protection constants.
By this time I was quite frustrated at the situation. Oftentimes I would work weekends just to fix other people's stuff (with all the bad implications that had - CVS conflicts and all). I eventually realized there was only one thing left to do: enforce the rules at CVS commit time.
That certainly got everybody's attention. Of course, many hated it. A few developers asked me to relax some of the rules, on the grounds that they're writing the code and nobody else will ever look at it. I thought that argument was bogus and refused to do it.
The complaints slowly subsided over the following months. I sure hope people realized that enforcing code consistency was, after all, a good thing, but it may well have been because developers gave up arguing over it with an obsessive compulsive consistency freak. New hires found the style checker in place and probably never felt like arguing about it either. Whatever the reasons were, the goal was achieved.
It wasn't all smooth, though. Sometimes the style checker would fail because somebody came up with a valid C++ syntax I didn't think of. Sometimes we had to make it skip certain modules that we were using but weren't developed in house - reformatting those to pass the style checker would've been really dumb. Sometimes the style checker would make commits really slow. Despite all these minor issues, I think the style checker was a good thing. And it certainly was a good source of jokes inside the company, with people comming up with all sorts of cute ideas about what what we could make it do. It was fun.
I still have somewhere on my computer a version of my C++ style checker script from the pre-Ecora days, and I hope one day I'll have the time to clean it up and make it available here, but I wouldn't hold my breath if I were you.
Let's see now the actual rules...