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.

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

Modern IDE's make this kind of religious stuff moot. Two keystrokes and the file looks the way the developer wants. Who cares what it looks like in source control. Of course, that makes finding edits a pain in the butt.
–
Robert C. BarthJan 12 '09 at 1:15

1

@RobertC.Barth: Why not just use rsync as your VCS? Has all the nice features: decentralized, ssh, compression. Gosh, who needs diff, blame and three way merges?
–
phresnelDec 16 '11 at 13:48

8 Answers
8

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.

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?

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.

As long as everyone agreed to an acceptable standard, I don't see why this couldn't be included as well as brace style and indentation.
–
Bill the Lizard♦Nov 12 '08 at 15:32

5

I like OpenBSD's idea on that. If you have to sacrifice readability to keep with the general standard, then don't do it. Readability is why the standard really got made in the first place. However, this should be the exception -- not the norm.
–
NazadusNov 15 '08 at 18:04

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).

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.

The same can be done with Java technologies for sure, and I'm reasonably confident there are Open Source tools available to perform the same in C/C++. Don't know about the newer scripting/dynamic languages.
–
Ken GentleNov 12 '08 at 15:34

Some tools like checkstyle allow you to do something similar in java
–
Mario OrtegónNov 24 '08 at 21:47

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.

Your IDE should also warn about using = in a condition. :-) For example, GCC with warnings turned on would insist that you write "if ((x = 1))" to signal your intent to actually use = instead of ==.
–
Chris Jester-Young♦Dec 25 '08 at 22:54

enh, maybe it's not C or Java code but some other language that uses = as the comparison operator :)
–
Mr. Shiny and New 安宇Jan 8 '09 at 18:03

+1, however, it should be part of the guidelines that code embedded in string literals should be the exception, not the rule :)
–
phresnelDec 19 '11 at 10:52

@phresnel: In many environments there's no good way to handle SQL natively; it can only be embedded in string literals. It IS annoying though.
–
Mr. Shiny and New 安宇Dec 19 '11 at 13:24

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.

I've updated the CodePainter project to now work tightly with EditorConfig, so you can get the best of both worlds for JavaScript, at least: github.com/jedhunsaker/codepainter
–
jedmaoMay 17 '13 at 4:56

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.