Should I use parenthesis around every operators?

Question

The facts

This is a very similar question to this one, but here I am talking about a more general case the MISRA-C3 Rule 5.0.2 or the SEI CERT C EXP00-C rule (more permissive).

Within MISRA-C3 I shall use parentheses to avoid implicit operator precedence. So the following code is correct, but to my eyes very boilerplate:

 if ((((x * y) + 3) > z) && ((w - 1) <= (42 + (x / (y + z)))))

Note: as I was writing this expression I had to copy/paste it in my code editor to fix the missing parenthesis because it got too cumbersome.

As an experienced programmer I would only use parenthesis for non-obvious precedence that may depend on the programming language I use. The C Operator Precedence Table may not be easy to learn, especially for new C programmers and sometime even for my self when I am tired by hours of programming in the middle of the night.

My rule of thumb is:

Parenthesis shall be used for explicit operator precedence with all operators except the logical and (&&) and or (||), and the 4 basic operations (* / + -).

The above expression can therefore be simplified like this:

 if ((x * y + 3) > z && (w - 1) <= (42 + x / (y + z)))

The latter expression looks much easier to read and I can see at a glance if I am missing a parenthesis.

Moreover, as the equal (=) operator also falls under the MISRA rule. Developers should also write z = (a * b) and not z = a * b.

The story behind

I am working in a company where the developers are far from experienced in C programming despite they all do C programming for more than 10-15 years. They keep adding useless comments x = 2; // Assign x with 2 everywhere and claims the first expression I wrote is much more readable because no human can learn by heart the operator precedence. So they usually use comments, parenthesis or forward declaration everywhere rather than using their common sense to keep the reading flow clear and understandable.

I was trying to teach them the beauty of programming where the programmer has to tell a story and keep the flow crystal clear by avoiding useless things they put everywhere because once someone told them to do so.

Today I am questioning myself and wondering if I am right or wrong about this parenthesis thing. Perhaps the first expression is more understandable than the second one for most people.

Examples

if ((i > LENGTH) && (((a * b) + c) > (d + e)))  // Bad
if (i > LENGTH && a * b + c > d + e)  // Good

y = ((x * y) + 1);  // Bad
y = x * y + 1;  // Good

The question

Is my rule of thumb (yellow box above) a good rule? The MISRA C3 Rule 5.0.2 is only advisory and CERT-C is more into my direction.

Answer 1

If you need to follow some standard, then follow that standard even if the advice seems suboptimal. Note that many coding standards and guidelines have a specific goal in mind. MISRA is geared towards security, and therefore wants to eliminate any possibly confusing constructs. As operator precedence can sometimes be confused even by experienced programmers, explicitly parenthesizing your expressions is in line with that goal.

For coding conventions within your organization, the goal probably isn't elegant, beautiful code, but maintainability by all programmers. Your coding conventions should be oriented around the lower end of the skill distribution in your team. This is basically the same issue as the recent Is it OK to use meta-programming? question. So don't do what's pretty in your eyes, do what is understood by all team members.

Note that all your code snippets are a red herring. I would flag most of your examples in a code review. Not because they do or don't use parentheses, but because these expressions are terribly complex. The whole parenthesisation issue is far less urgent if you extract sub-expressions as separate variables. As an added benefit, these variable names can make the code more self-documenting. Even if no one else does this, you can use such techniques to improve code that you write.

Answer 2

Well, I would write your example almost exactly as you stated is the "bad way", because I'm not writing it for me, I'm writing it for the next engineer(s), and they may not have the understanding of the functionality down as much as I do.

Let's take the second (simple) example in your last code block:

y = ((x * y) + 1);  // Some valuable comment here or maybe no comment at all

This makes the future person reading the code (and possibly changing it) understand that I'm setting y to the increment of the product, versus the product of the increment. To me, when I've read code written by someone years ago and I'm looking for an understanding of what's going on, this version makes me quickly see that the product is incremented.

y = x * y + 1;  // Possibly some useless comment

My initial quick, barely-a-glance reading (because I'm pressed for time, have no good understanding of the code, and really want to get back to YouTube development) might not get that the product is incremented, especially if the comment is a little vague. Now I have to stop my barely-a-glance reading and think about:

1. What they wanted to do
2. What they really did
3. What might happen if they didn't do what they wanted

Explicit parentheses? I personally love them when I'm writing and I love them when I'm reading. One thing I do do is to use temporary variables and white-space to my benefit so that it's easier to read.

Taking the first example:

if ((((x * y) + 3) > z) && ((w - 1) <= (42 + (x / (y + z)))))

I would write as (if I didn't want to use temp variables):

if (   (((xDim * yDim) + PROD_OFFSET) > zVolume)
    && ((wDim - EDGE_FACTOR) <= (MAX_THRESH + (xDim  / (yDim + zVolume)))))
{
...
}

Now it's easier for me to see that there are two (2) conditionals that must be met (now each on their own line) and my variables and constants now make a bit more sense. (I know the variable and constant names were random for your example, but I wanted to show a complete comparison.)

Parenthesis/brace matching? Good IDEs (with integrated LINT) always let you know ahead of time.