Coding Standards and Guidelines

In general – at least, in my experience – coding standards do not provide rules on how to parenthesise expressions. I suspect this is for two reasons.

Firstly, because although all programmers use parentheses to clarify the meaning of expressions, they may well disagree on what makes an expression clear. Clarity seems a matter of taste. While programmers in a team may agree (to differ) on whether tabs or spaces are to be used for indentation, their coding standard leaves them free to rewrite Example 4 as:


str += errors == 0 ? "succeeded" : "failed"

And secondly, if a coding standard were to rule on how to parenthesise, it would be difficult to find a middle ground. This leaves as candidate rules the two extremes:

parenthesise everything
never parenthesise

The first quickly leads to unreadable code, and the second seems overly proscriptive.

In the absence of a hard rule, here are some guidelines which I hope are non-contentious and which may help us reach a conclusion:

have the operator precedence tables to hand and understand how to interpret expressions using them,
understand the logic behind the operator precedence tables, but be aware of the traps and pitfalls,
remember, parentheses are not the only way to make order of evaluation clear. For example, Example 4 could be rewritten:

*utf++ = 0x80 | 
              ucs >> 6 & 
              0x6f

or even:

*utf = ucs >> 6; 
*utf &= 0x6f; 
*utf |= 0x80; 
++utf;

if an expression is hard to understand, break it down into simpler steps, or extract it out as a function with a meaningful name,
trust the compiler: it might not implement partial template specialisation correctly, but it will get operator precedence right every time,
never use parentheses simply because you aren't sure of how an expression will be evaluated without them: treat doubt as an opportunity to learn,
all macro arguments must be parenthesised.