Most crucial elements in a light-weight C++ coding

Question

I've been involved in developing coding standards which were quite elaborate. My own experience is that it was hard to enforce if you don't have proper processes to maintain it and strategies to uphold it.

Now I'm working in, and leading, an environment even less probable to have processes and follow-up strategies in quite a while. Still I want to uphold some minimum level of respectable code. So I thought I would get good suggestions here, and we might together produce a reasonable light-weight subset of the most important coding standard practices for others to use as reference.

So, to emphasize the essence here:

What elements of a C++ coding standard are the most crucial to uphold?

• Answering/voting rules

  • 1 candidate per answer, preferably with a brief motivation.

  • Vote down candidates which focuses on style and subjective formatting guidelines. This is not to indicate them as unimportant, only that they are less relevant in this context.

  • Vote down candidates focusing on how to comment/document code. This is a larger subject which might even deserve its own post.

  • Vote up candidates that clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.

  • Don't cast your vote in any direction on candidates you are uncertain about. Even if they sound reasonable and smart, or on the contrary "something surely nobody would use", your vote should be based on clear understanding and experience.

Answer 1

Pass input arguments by const reference, and output or input-output arguments by pointer. This is a rule borrwed from the Google style guide.

I used to have an absolute aversion to pointers and preferred to use references whenever possible (as suggested by one of the posters in this thread). However, adopting this output-arg-as-pointer convention has made my functions much more readable. For example,

SolveLinearSystem(left_hand_side, right_hand_side, &params);

makes it clear that "params" is being written to.

Answer 2

Side note: Do not impose SESE (Single Entry Single Exit) (i.e. do not forbid more than one return, the use of break/continue/...)

In C++, this is an utopia as throw is another return point. SESE had two advantages in C and exception-less languages:

• the deterministic release of resources that is now neatly handled by the RAII idiom in C++,
• making functions easier to maintain, that should not be a concern as the functions must be kept short (as specified by the rule of "one function, one responsibility")

Answer 3

Prefer RAII.

STL's auto (and shared in boost & C++0x) pointers may help.

Answer 4

Only trivial use of the ? : operator, i.e.

float x = (y > 3) ? 1.0f : -1.0f;

is ok, but this is not:

float x = foo(2 * ((y > 3) ? a : b) - 1);

Answer 5

Whatever guidelines, make it very easy to recognize applicability: the less choice you have, the less time you loose choosing. And the easier it becomes to brainparse the code.

Examples of 'hard to recognize':

• No braces if only one line in the conditional body
• Use K&R brace placement for namespaces, but put brace underneath conditions in function definition code
• ...

Answer 6

Curly braces required if you have more than one step of indentation:

if (bla) {
  for (int i = 0; i < n; ++i)
    foo();
}

This helps to keep indentation in line with how the compiler sees the code.