Should One Know Operator Precedence thoroughly?

Question

Should the programmer be aware of operator precedence thoroughly? Using braces to group expressions should be okay, isn't? I always uses braces to be on safer side. And when asked a question on precedence, I cannot answer readily.

Answer 1

Yes, it's important to understand operator precedence. However, I think there's value in using parentheses to be perfectly clear about your intention. It will help readability and maintainability.

Answer 2

I know the basics (e.g., division and multiplication higher than addition and subtraction), but I would have to look up something more esoteric.

I usually use parentheses to make my intention clear. I think it reads better, and avoids errors due to incorrect assumptions.

Answer 3

It certainly couldn't hurt, and can help you read code with precendence subtleties written by others.

In practice, though, it's probably better not to assume that those maintaining your code will have the same skill, so while should be able to read this code you may not want to write code that takes too much advantage of the interactions. Better to use constructs that are unmistakable, even if it means a few extra parentheses here and there.

Answer 4

I think it's important to understand the basic predidence rules. I find knowing the nitty gritty details to be not worth the time. Mainly because any case where predecence is ambiguous can be solved with a simple set of parens. Secondly because not everyone knows them and it's best to make your code readable to the users in your group.

At one time in college, i used to know all of the predence rules by heart. Once I got into the real world I found most people did not know them by heart. If i checked in some valid code which depended upon some predecence rules I consistently got the same feedback "add parens to make it obvious".

Answer 5

For very common operators - yes, it's worth knowing it. If you put brackets round everything that would otherwise rely on operator precedence, your code would be unreadable (or easily confused with Lisp).

For more obscure operators - I've explicitly avoided learning them. If I start taking too many things for granted that I can't reasonably expect other developers to know, I'll start writing code which I can read easily but no-one else can. The best example is shift operators. I don't even know (for sure - I have an inkling) which of these would be treated the same without the brackets, but I'm absolutely sure which is clearer:

int x = (y << shift) + offset;

or

int x = y << (shift + offset);

Answer 6

I'm with you on this one; using braces to make the precedence explicit is always a good idea. It makes your code easier to read, and your intentions are explicit.

With that said, you should know where to look up information on operator precedence, in case you are maintaining others' code.

Answer 7

You should understand it to be able to read the code written by someone who hasn't used parens everywhere.

I don't think "always-braces" is a good rule of thumb. Code that has too many parens gets harder to read than necessary. Like:

(a * b) + c

is just silly. There's a balance somewhere and the challenge is to find it. Like so many other things it's about applying common sense.

Answer 8

Practically: Not really. If it's so complicated that you have to know operator precedence, you should probably break up the expression into chunks anyway. Also, parenthesis will save you!

Professionally: It doesn't take long to learn the order for your language of choice and can come in handy when reading other people's code. If nothing else, just keep it on a cheat-sheet on your cube wall.

Answer 9

You should understand it, but you should not assume that others will. I always use parenthesis to make the precedence explicit.

Answer 10

I use a cheat sheet for all but the most common arithmetic operators. If something is the least bit tricky, I use explicit parentheses to make my intentions clear.

The reason I like using a written guide rather than memorizing precedence is that I often work in multiple languages with subtly different rules. Memorizing anything beyond the most common operators can lead to errors when I begin to rely too much on my memory.

Answer 11

No!

If you are unsure of the precedence then its probable that anyone else reading the code would be liable to interpret it wrongly.

If you are unsure just

 ( .. ) 

the relevent bits of code then there is no ambiguity for you or anyone else.

Answer 12

There's a third option. Rather than memorizing all those rules, or using parentheses to make sure of everything...

If your expression is so long that it's not clear what happens first, break it up into multiple lines, using temp variables for intermediate results. Then you're introducing clarity without the clutter of parentheses, and you can use descriptive names for the temp variables to make things even more clear.

Answer 13

I never have a 100% grip on the precedence rules because I work in several languages (C, C++, perl, bash, and once in a while a dash of TCL/TK.). At various times over the years I've worked with several different assembly languages and a non-conforming compiler or two.

I CAN'T keep the fully detailed precedence rules straight in my head - I have to switch among rule sets too often.

Answer 14

Quick, which has higher precedence in T-SQL: AND versus OR.

SELECT c.Name
FROM [Customer] c LEFT JOIN [Order] o
  ON c.CustomerKey = o.CustomerId
WHERE c.Name like 'B%'
  OR c.Name like 'Z%'
  AND o.CustomerId is NULL

Once you learn the precedence of these operators to the point you rely on that precedence, you're doomed either to:

• Use them wrong yourself.
• Suffer the mistakes of others, who will not learn these operators and cannot read your code.

Answer 15

Yes For:

• * / + -
• && || And Or

No/Maybe:

• << >> & | ^

Answer 16

Years ago I saw this precedence table for C:

• Multiplication and division occur before addition and subtraction.
• Use parentheses.

That's slightly over simplified, but it has the right idea.

Answer 17

It is very very easy to fool yourself when writing a == a & some_flag.

Even if I would suggest not learning precedence rules, using parentheses and temporaries for clarity (remember : code is meant to be read by human beings), sometimes an operator precedence table comes in handy.