Enforcing a coding style

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

That sounds like a good idea. As long as the style you end up with is not something completely strange, that's a good way to make sure your developers use the style. And it has the added benefit that they don't have to code that way - it will get reformatted for them when they check in their changes. It would be nice to have a tool like that available that you can plug into your CVS (generic term).

Answer 2

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 3

If you limited it to enforcing style on braces and indentation, then I think it's a good idea. However, if you were to try to enforce every single formatting standard, then it probably wouldn't be. In my opinion, there are times when it makes sense to break the standard. For example, I prefer

int x = y * z;

to

int x = y*z;

because it's easier to read. However, I vastly prefer

int a = b*c + d*e;

to

int a = b * c + d * e;

because the spacing represents the order of operations.

So your policy of enforcing indentation and braces sounds really good. But if someone ever tried to blindly enforce other spacing rules, I don't think it would work well.

Answer 4

We use TFS with a check in policy that runs a set of Stylecop rules. If your code doesn't pass, you can't check it in. Works very well indeed. Aside from a consistant style and good commenting throughout, it also seems to have increased the general quality of the code - perhaps because the developer is forced to describe what every method, event, etc does they are forced to think about the code more before check in.

Only an MS solution, but worthwhile if it's available to you.

Answer 5

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.

Answer 6

The biggest problem with using automatic code formatters is when the code formatter can't handle every scenario.

For example, if you have lots of SQL in your code, you probably format the SQL automatically. But if your SQL is longer than one line (how long is a line, anyway?) then you have to format it. So far I've yet to see a good formatter than can deal with this properly.

Example:

String sql = "SELECT * FROM USERS WHERE ID = ? AND NAME = ? AND IS_DELETED = 'N'";

vs

String sql = 
  "SELECT * " +
  "FROM USERS " + 
  "WHERE ID = ? " + 
  "  AND NAME = ? " +
  "  AND IS_DELETED = 'N'";

The second format is more readable when you have really long queries. Most formatters would de-format that into one long line up to the line length.

However if all you're doing is turning

if(x=1) print("blah"); else print("eep!");

into

if (x = 1) {
  print("blah");
} else {
  print("eep!");
}

then the formatter is ok. We do something similar at work; it isn't enforced by the CVS tool but rather by the IDE. Works reasonably well.

Answer 7

I believe you have decided on your development environment by now. If you use Eclipse you can enable the Format Source save action on the Java editor, which reformats at every save. The major benefit from this is that source chances are marked in your source repository at the time when they were done, not when the source was reformatted later.

Make it an automatic step. You will appreciate it later.