I'm firmly in the camp that doesn't care what the rule/style is, I just want an unambiguous rule. I'll just use whatever the language conventions are. Snake case in Java, for example, would be a hate crime. So would camel case in C.
My general preferences beyond that are:
- Opening braces on the same line (I see the article has examples where it's on a new line);
- Two space indent, no tabs
- No trailing white space. This should be automatically removed so it doesn't generate extraneous changes on commit;
- A reasonable line length between 80 and 120 characters, depending on the language. You need to be able to look at 3 files side by side without wrapping.
- Don't put the return type on a separate line. This is a really old school (K&R) C style
- Don't align function parameters with opening parentheses. Change the function name and you generate a bunch of changed lines for the parameters.
- No space before semi-colons eg for (i=1; i<100; i++) not for (i = i ; i < 100 ; i++ )
I would love to see a space advocate's response to this, mostly so I can disregard it because they are heathens on the wrong side of a holy war, but also because this is the only argument I've ever heard one way or another which seems to boil down to anything more than opinion.
There are two classes of rules here: naming and formatting. Formatting can be completely automated and thus changed at will, even locally with git hooks. Whitespace can be made truly insignificant with the proper tools.
While you could apply the same kind of automated logic to naming, the risk of collision is non zero and moreover would likely break runtime mechanisms like reflection, etc.
1. You're writing C++. You've really lost half the battle laready :) and
2. Writing correct templated code is difficult and should generally be reserved for when you're writing a library; and
3. For complicatred types like this, one should strive to increase readability by using type aliases, assuming your language supports it (eg C++ and Hack do). It's not always possible.
My general preferences beyond that are:
- Opening braces on the same line (I see the article has examples where it's on a new line);
- Two space indent, no tabs
- No trailing white space. This should be automatically removed so it doesn't generate extraneous changes on commit;
- A reasonable line length between 80 and 120 characters, depending on the language. You need to be able to look at 3 files side by side without wrapping.
- Don't put the return type on a separate line. This is a really old school (K&R) C style
- Don't align function parameters with opening parentheses. Change the function name and you generate a bunch of changed lines for the parameters.
- No space before semi-colons eg for (i=1; i<100; i++) not for (i = i ; i < 100 ; i++ )