Enforcing a coding style [closed]

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

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 3

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.

Answer 4

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 5

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 6

There is a project called EditorConfig can somewhat solve the issue. However, it currently only solves indentation issues.

EditorConfig contains plugins for many different editors, and a file format standard. By creating an .editorconfig file in the root of your project, and installing the corresponding plugin, the editor will format your code when you type them.

This is a general way (unlike indentrc, not limited to C/C++), but you can still take a look at this solution.