Should I fully parenthesize expressions or rely on precedence rules?

Question

Let's say I have a boolean condition a AND b OR c AND d and I'm using a language where AND has a higher order of operation precedence than OR. I could write this line of code:

If (a AND b) OR (c AND d) Then ...

But really, that's equivalent to:

If a AND b OR c AND d Then ...

Are there compelling arguments in favor or against including the extraneous parentheses?
Does practical experience suggest that including them significantly improves readability?
Or is wanting them a sign that a developer really needs to sit down and become conversant in the basics of their language?

Answer 1

Good developers strive to write code that is clear and correct. Parentheses in conditionals, even if they are not strictly required, help with both.

As for clarity, think of parentheses like comments in code: they aren't strictly necessary, and in theory a competent developer should be able to figure out code without them. And yet, these cues are exceedingly helpful, because:

• They reduce the work required to understand the code.
• They provide confirmation of the developer's intent.

Furthermore, extra parentheses, just like indentations, whitespace, and other style standards, help visually organize the code in a logical way.

As for correctness, conditions without parentheses are a recipe for silly mistakes. When they happen, they can be bugs that are hard to find--because often an incorrect condition will behave correctly most of the time, and only occasionally fail.

And even if you get it right, the next person to work on your code may not, either adding errors to the expression or misunderstanding your logic and thus adding errors elsewhere (as LarsH rightly points out).

I always use parentheses for expressions that combine and and or (and also for arithmetic operations with similar precedence issues).

Answer 2

It matters less whether you are confident in your grasp of the language. What matters more is the grasp of the language of the n00b that follows you.

Write your code in the clearest most unambiguous way possible. Extra parenthesis often (but not always) help. Putting only one statement on a line often helps. Consistency in coding style often helps.

There is such a thing as too many parenthesis, but it's one of those situations where you won't need advice - you'll know it when you see it. At that point refactor your code to reduce the complexity of the statement rather than remove parenthesis.

Answer 3

Yes

You should always use parentheses... you do not control the order of precedence... the developer of the compiler does. Here is a story that happened to me about non use of parentheses. This affected hundreds of people over a two week period.

Real World Reason

I inherited a main-frame application. One day, out of the blue, it stopped working. That's it... poof it just stopped.

My job was to get it working as fast as possible. The source code had not been modified for two years, but all of the sudden it just stopped. I tried to compile the code and it broke on line XX. I looked at line XX and I could not tell what would make line XX break. I asked for the detailed specs for this application and there were none. Line XX was not the culprit.

I printed out the code and started reviewing it from the top down. I started to create a flowchart of what was going on. The code was so convoluted I could hardly even make sense of it. I gave up trying to flowchart it. I was afraid to make changes without knowing how that change would effect the rest of the process, especially since I had no details of what the application did or where it was in the dependency chain.

So, I decided to start at the top of the source code and add whitespace and line breaks to make the code more readable. I noticed, in some cases, there were if conditions that combined AND and OR statements and it wasn't clearly distinguishable what data was being ANDed and what data was being ORed. So I started putting parentheses around the AND and OR conditions to make them more readable.

As I slowly moved down cleaning it up, I would periodically save my work. At one point I tried compiling the code and a strange thing happened. The error had jumped passed the original line of code and was now further down. So I continued, separating the AND and OR conditions with parens. When I got done cleaning it up it worked. Go figure.

I then decided to visit the operations shop and ask them if they had recently installed any new components on the main-frame. They said yes, we recently upgraded the compiler. Hmmmm.

It turns out that the old compiler evaluated expressions from left to right regardless. The new version of the compiler also evaluated expressions from left to right but ambiguous code, meaning unclear combinations of AND and OR could not be resolved.

Lesson I learned from this... ALWAYS, ALWAYS, ALWAYS use parens to separated AND conditions and OR conditions when they are used in conjunction with each other.

Simplified Example

`IF Product = 191 OR Product = 193 AND Model = "ABC" OR Product = 201 OR Product = 202 AND Model = "DEF" ...` (code littered with several of these)

This is a simplified version of what I encountered. There were else conditions with compound boolean logic statements as well.

I remember changing it to:
`IF ((Product = 191 OR Product = 193) AND Model = "ABC") OR ((Product = 201 OR Product = 202) AND Model = "DEF") ...`

I couldn't rewrite it because there were no specs. The original author was long gone. I remember intense pressure. An entire cargo ship was stranded in port and could not be offloaded because this little program did not work. No warning. No changes to the source code. It only dawned on me to ask the Network Operations if they modified anything after I noticed that adding parens shifted the errors.

Answer 4

Yes, if there are mixed 'and' and 'or'.

Also good idea to () what is logically one check.

Though best is to use well-named predicate functions and evict most checks and conditions there, leaving if simple and readable.

Answer 5

The parentheses are semantically redundant, so the compiler doesn't care, but that's a red herring--the real concern is programmer readability and comprehension.

I'm going to take the radical position here and give a hearty "no" to the parentheses in a AND b OR c AND d. Every programmer should know by heart that precedence in Boolean expressions goes NOT > AND > OR, just like remembering Please Excuse My Dear Aunt Sally for algebraic expressions. Redundant punctuation just adds visual clutter most of the time in code with no benefit in programmer readability.

Also, if you always use parentheses in logical and algebraic expressions, then you give up the ability to use them as a marker for "something tricky is happening here--look out!" That is, in the cases where you want to override default precedence and have addition evaluated before multiplication, or OR before AND, parentheses are a nice red flag to the next programmer. Too much use of them when they're not needed, and you become the Boy Who Cried Wolf.

I would make an exception for anything outside the realm of algebra (Boolean or not), such as pointer expressions in C, where anything more complicated than standard idioms like *p++ or p = p->next probably ought to be parenthesized to keep the dereferencing and the arithmetic straight. And, of course none of this applies to languages like Lisp, Forth, or Smalltalk that use some form of Polish notation for expressions; but for the majority of mainstream languages, logical and arithmetic precedence are totally standardized.

Answer 6

As I see it:

YES Pros:

• Order of operations is explicit.
• Protects you from future developers who don't understand order of operations.

YES Cons:

• May result in cluttered, difficult to read code

NO Pros:

• ?

NO Cons:

• Order of operations is implicit
• Code is less maintainable for developers without a good understanding of order of operations.

Answer 7

Are there any arguments in for or against including the extraneous parentheses? Does practical experience suggest that it is worth including them for readability? Or is it a sign that a developer needs to really sit down and become confident in the basics of their language?

If no one else ever would have to look at my code again, I do not think I would care.

But, from my experience:

• I look at my code again occasionally (sometimes years after writing it)
• Others sometimes look at my code
  • Or even have to expand/fix it!
• Neither myself or the other remembers exactly what I was thinking when writing it
• Writing cryptic "minize the character count" code hurts readability

I almost always do this because I trust my ability to quickly read and not make little mistakes a lot more with parens than nothing else.

In your case, I would almost assuredly do something like:

if (a AND b) then ab = true
if (c AND d) then cd = true
If (ab OR cd) Then ...

Yes, it's more code. Yes, I can do fancy bool operators instead. No, I don't like the chance when skimming code 1+ years in the future I misread fancy bool operators. What if I was writing code in a language which had different AND/OR precedence and had to jump back to fix this? Am I going to go, "aha! I remember this clever little thing which I did! I didn't have to include parens when I wrote this last year, good thing I remember now!" if that happens (or worse, someone else who wasn't aware of this cleverness or was thrown into a "fix asap" type situation)?

Separating with () makes it so much more straightforward to quickly skim and understand later...

Answer 8

General case

In C#, multiplication and division has a precedence over addition and subtraction.

Still, StyleCop, a tool which enforces common style across the codebase with an additional goal to mitigate the risk of bugs introducing by code which may not be clear enough, has the rule SA1407. This rule will produce a warning with a piece of code like this:

var a = 1 + 2 * 3;

It's clear that the result is 7 and not 9, but still, StyleCop suggests to put parenthesis:

var a = 1 + (2 * 3);

Your particular case

In your particular case, there is a precedence of AND compared to OR in the particular language you use.

This is not how every language behave. Many others treat AND and OR equally.

As a developer who works mostly with C#, when I saw your question the first time and read the piece of code without reading what you've wrote before, my first temptation was to comment that the two expressions are not the same. Hopefully, I've read the whole question entirely before commenting.

This particularity and the risk that some developers may believe that AND and OR have the same priority makes it even more important to add parenthesis.

Don't write code with a goal to show that you're smart. Write code with a goal of readability, including by people who may not be familiar with every aspect of the language.

Answer 9

As everyone said, use parentheses everytime it makes the expression more readable. However if the expression is complicated I'd advise to introduce new functions for the subexpressions.

Answer 10

Or is it a sign that a developer needs to really sit down and become confident in the basics of their language?

If you strictly use language in singular, maybe. Now take all the languages you know, from ages old to most modern, from compiled to scripting to SQL to your own DSL you've invented last month.

Do you remember the exact precedence rules for each of these languages, without looking?

Answer 11

I will use parenthesis even if it is optional, why because it helps to better understand for everyone, for the one who write the code as well as the one ready to see that code. In your case even the boolean operators have precedence it might work well at first, but we can't say it will help you in every case. so i prefer to user parenthesis in any condition that it may require it or optionally.

Answer 12

"Should I use parentheses in logical statements even where not necessary."

Yes, because two people will find them helpful:

• The next programmer, who's knowledge, competency or style may be different

• The future you who returns to this code at some later date!

Answer 13

Yes. You should use in any case when you feel your code will be more clear. Remember your code should be clear enough so that others can understand without reading your comments inside the code. So it is a good practice to use parentheses and braces. Also keep in mind that it may be depends on the particular practice of your company/team. Just maintain one approach and do not mix.

Answer 14

• I just got back from your funeral. (Sorry about that bread truck, pal ...)

• Or maybe, you just don't work here anymore, and you've changed your phone number.

• I have never seen your code before. Among tens of millions of lines of stuff, I just encountered yours.

• The fires of business urgency are breathing down my neck. "Pres-sure!"

• So ...

• "Anything that you can do to make your code more clear(!) is priceless!"

• Because, "here's what keeps me up at night, because it's cost me a lot of sleep and my employer a lot of money." I glance at a line of code, think that I understand what it is doing, but I am wrong. "This WAS the bug that I was looking for, and I just missed it."

• Therefore, "please write your code stupid-simple clear, and accompany it with lots of comments. Thank you very much. "The compiler or interpreter doesn't care either way, but I do, because I have to!"

• My all-too-often pounded forehead will also thank you. "D'oh" is not something that I wish to say!

Answer 15

Complex conditionals are "boolean algebra", which you write in some ways that, well, make it look pretty much exactly like algebra, and you'd definitely use parens for algebra, wouldn't you?

The really useful rules are the negation ones:

!(A || B) <=> !A && !B
!(A && B) <=> !A || !B

Or, in a little clearer format:

!(A + B) <=> !A * !B
!(A * B) <=> !A + !B

which is really clearly just algebra when written as:

-1*(A + B) = -A + -B
-1*(A * B) = -A * -B

But we can also apply the thinking for algebraic simplification and expansion:

(A && B) || (C && D) => 
((A && B) || C) && ((A && B) || D) => 
(AC && BC) && (AD && BD) =>
AC && BC && AD && BD

although in code you have to write:

(A||C) && (B||C) && (A||D) && (B||D)

or, in a little clearer format:

(A + B) * (C + D) => 
((A + B) * C) + ((A + B) * D) => 
(AC + BC) + (AD + BD) =>
AC + BC + AD + BD

Basically, a conditional is still just an algebraic expression, and by clearly using parenthesis, you can more easily apply the various algebraic rules you already know to the expression, including ye olde concept of "simplify or expand this formula".