Enforcing a coding style [closed]

Question

Years ago when I was starting a small development project, the other developers and I sat down and agreed on a compromise brace and indentation style. It wasn't anybody's favourite, but it was something that nobody really hated. I wrote a .indentrc configuration file to that style, and had a check-in trigger that would run indent on every file as it was being checked in. That made it so that it didn't matter what style you wrote your code in, it would end up being the group standard before anybody else saw it. This had the advantage of consistency. But I've never seen anybody else do it this way before or since.

So what say the rest of you? Great idea, or abomination?

Answer 1

I'd say good idea. I'd take it a step further and make everyone use the config file in their IDE so that they were writing in the agreed upon style by default. If they're going to have to look at everyone else's code in the neutral style, they might as well get used to it. Even their own code should be in the neutral style after one check-in check-out cycle, so why develop new code in their own personal style?

Answer 2

Adopting a neutral coding style is definitely a good idea. However, only enforcing the coding style when the source is checked in may or may not be a good idea (see also Bill's and Elie's answers below).

Using the check-in hook:

Pro: Allows coders to write however they wish, so they don't have to think about the standard or change the way they write code. This minimizes resistance to the policy, and won't negatively impact their productivity when writing code.

Con: Your coders may have only a passing familiarity with the neutral style, so you aren't getting the full benefit of everyone using "the same" style. If your programmers ever have to work together in a pair programming setup, they are still going to be subjected to one another's programming style on the screen, which is going to be different from their own style or the neutral style.

Going one step further, using the neutral style during development:

Pro: Encourages fluency in the neutral style, everyone can always read everyone else's code before and after it's checked in.

Con: You'll encounter more resistance from your developers doing it this way. Depending on your culture, it could be more trouble than it is worth.