It is definitely refreshing to see some actual evidence in something where arguments tend to be based on speculation, experience, or opinion. Now, we just need someone to research Emacs v. Vim, Tabs v. Spaces, etc.
Not exactly this, but there exists "Program indentation and comprehensibility" http://www.cs.umd.edu/~ben/papers/Miara1983Program.pdf which tries to tackle the "2 spaces vs 4 spaces vs 8 spaces indent". Not very good tho, since they seem to add superfluous indent levels like a separately indented "then" after "if" (Pascal), which effectively doubles the actual indent of the semantic block.
Braces really are evil, just because of how much time is spent bikeshedding about them. In what universe will a program function better if braces are on the end of the line or the next?
That's one thing I really like about go. It's nearly as opinionated about its braces as Python is about its not-braces (almost...).
Any development environment where there exists a rule on Braces versus Indents is a place I'd stay well away from.
Put braces where they make the code readable. Use indents instead where they make the code more readable.
And if you do need a rule, make sure it's based on actual need. I.e. start the discussion with "the past two months we've had 4 non-trivial bugs which could have been avoided if we enforced braces.", not have a bunch of people bicker about their Personal Preferences (usually goes by the name "Best Practices").
I disagree. I prefer a development environment that settles on a coding style, even if I don't like it, rather than chaos. I find reading code using multiple coding style painful.
It also ends the bikeshedding, "that's how we do it there, deal with it".
Such binary arguments bother me - Things won't degenerate to complete and utter chaos unless you go and add strict rules for everything. Good developers tend to follow the style of code they're in, and over time converge on a consistent style within projects or at least modules.
If they don't respect existing style, you don't have a "lack of rules" problem. You have a lack of education problem. Do code reviews. Point out to Bob that he's making the code less by letting the style alternate.
But you're sort of touching on what I meant when you say you don't want "chaos". If you can point at a code file and say "this is chaotic and hard to read - we could improve that by converging on style X or Y.", then we could come to some agreement.
Personally, I'd rather deal with slight aberrations in style than having a flaming row and angering half my team.
