Learning the operators' rules

[Udyant Wig]

I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

[Siri Cruz]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

Don't. There's no penalty for parenthesising more than strictly necessary.

[Malcolm McLean]

Post by Siri Cruz

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

Don't. There's no penalty for parenthesising more than strictly necessary.

The rule of three.
A human cannot parse more than three levels of nested parentheses without
resorting to strategies like counting or arranging the data in columns.

[Richard Heathfield]

Post by Malcolm McLean

Post by Siri Cruz

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

Don't. There's no penalty for parenthesising more than strictly necessary.

The rule of three.
A human cannot parse more than three levels of nested parentheses without
resorting to strategies like counting or arranging the data in columns.

Conclusion: I'm not human.

[crankypuss]

Post by Richard Heathfield

Post by Malcolm McLean

Post by Siri Cruz

Post by Udyant Wig
I am looking at the table of operator precedence and associativity
rules in Harbison and Steele, and I am wondering how (if?) I should
go about memorizing it, beside writing it out by hand over some
days.

Don't. There's no penalty for parenthesising more than strictly necessary.

The rule of three.
A human cannot parse more than three levels of nested parentheses
without resorting to strategies like counting or arranging the data
in columns.

Conclusion: I'm not human.

The rule of one.

Anyone who writes complex code to show off how inhumanly intelligent he
is has doomed himself to having to read that kind of shit later when
he's older and maybe not as smart as he thought he was when he was
bragging about writing code you need an IQ of 400+ to fix.

The people who end up maintaining your code are hardly ever as smart as
you were when you wrote it, if you don't want them calling you on the
phone at 3am (or equivalent) to ask you how to fix it, write really
stupid code.

[Richard Heathfield]

Post by crankypuss

Post by Richard Heathfield

Post by Malcolm McLean

Post by Siri Cruz

Post by Udyant Wig
I am looking at the table of operator precedence and associativity
rules in Harbison and Steele, and I am wondering how (if?) I should
go about memorizing it, beside writing it out by hand over some
days.

Don't. There's no penalty for parenthesising more than strictly necessary.

The rule of three.
A human cannot parse more than three levels of nested parentheses
without resorting to strategies like counting or arranging the data
in columns.

Conclusion: I'm not human.

The rule of one.
Anyone who writes complex code to show off how inhumanly intelligent he
is has doomed himself to having to read that kind of shit later when
he's older and maybe not as smart as he thought he was when he was
bragging about writing code you need an IQ of 400+ to fix.

I know it, which is why I write code as clearly and simply as possible.
The fact that I /can/ parse more than three levels of nested parentheses
does /not/ imply that doing so is in my top ten list of hobbies.

[Gareth Owen]

Post by Richard Heathfield

Post by Malcolm McLean
The rule of three.
A human cannot parse more than three levels of nested parentheses without
resorting to strategies like counting or arranging the data in columns.

Conclusion: I'm not human.

Conclusion: LISP programmers aren't human.

[Richard Heathfield]

Post by Gareth Owen

Post by Richard Heathfield

Post by Malcolm McLean
The rule of three.
A human cannot parse more than three levels of nested parentheses without
resorting to strategies like counting or arranging the data in columns.

Conclusion: I'm not human.

Conclusion: LISP programmers aren't human.

That's actually true, though, isn't it?

<g,d&r>

[Keith Thompson]

Post by Malcolm McLean

Post by Siri Cruz

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

Don't. There's no penalty for parenthesising more than strictly necessary.

The rule of three.
A human cannot parse more than three levels of nested parentheses without
resorting to strategies like counting or arranging the data in columns.

You repeat this claim in the face of numerous counterexamples.

[Stephen Sprunk]

Post by Keith Thompson

Post by Siri Cruz
Don't. There's no penalty for parenthesising more than strictly necessary.

The rule of three. A human cannot parse more than three levels of
nested parentheses without resorting to strategies like counting or
arranging the data in columns.

You repeat this claim in the face of numerous counterexamples.

It may be incorrect in specific cases, but as a general guideline when
you don't know who will be maintaining your code in the future, three
levels seems like a good practical limit. Like any guideline, though,
it can be broken when doing so is the less-bad choice.

S

[crankypuss]

Post by Malcolm McLean

Post by Siri Cruz

Post by Udyant Wig
I am looking at the table of operator precedence and associativity
rules in Harbison and Steele, and I am wondering how (if?) I should
go about memorizing it, beside writing it out by hand over some
days.

Don't. There's no penalty for parenthesising more than strictly necessary.

The rule of three.
A human cannot parse more than three levels of nested parentheses
without resorting to strategies like counting or arranging the data in
columns.

Doubtless true for some values of "human", but if none of us can handle
more than three levels of nesting, probably some of us can't even handle
that many. Call me a Luddite but I still prefer the way Assembler does
it, no freaking parentheses at all, spell it all out; it's easier to
maintain that way imo, and frankly I think it's easier to develop too,
seeing that you don't make all those mistakes between semantics and
syntax when you think you wrote what you thought you wrote but didn't
because the compiler is doing all the work of confusing you to save you
effort. Likewise nested conditional code, the nesting limitations of
the human mind aren't only limited in one way. KISS, imo.

[Malcolm McLean]

Post by crankypuss

Post by Malcolm McLean
The rule of three.
A human cannot parse more than three levels of nested parentheses
without resorting to strategies like counting or arranging the data in
columns.

Doubtless true for some values of "human", but if none of us can handle
more than three levels of nesting, probably some of us can't even handle
that many. Call me a Luddite but I still prefer the way Assembler does
it, no freaking parentheses at all, spell it all out; it's easier to
maintain that way imo, and frankly I think it's easier to develop too,
seeing that you don't make all those mistakes between semantics and
syntax when you think you wrote what you thought you wrote but didn't
because the compiler is doing all the work of confusing you to save you
effort. Likewise nested conditional code, the nesting limitations of
the human mind aren't only limited in one way. KISS, imo.

The rule of three was my first programming rule, and was the nucleus
that inspired me to write the "Ten Rules of Programming".
It was initially derived from empirical observation. C++ encourages the
use of "access functions" of the form cursor.x(). I realised that these
tended to be embedded in expressions, and it was jolly hard to read.
I worked out that cut off was about three levels of nesting, beyond that,
the parentheses ceased to make the expressions easier to read.

Independently of that, I'd worked out that three levels of indirection
were about the limit for readable code. You can have a char * for a string,
a char ** for a list of strings, and a char *** for a reference to a list of
strings, but go to char **** and it starts to get silly.

But parenthesis trees and indirection are different notations for the same
concept, which is also the basically same thing as an array dimension.
And of course you can only visualise three dimensions. So I suspect that is
the psychological underpinning of the rule of three.

[Richard Heathfield]

Post by Malcolm McLean
And of course you can only visualise three dimensions.

I can visualise more than three dimensions. Sorry, Malcolm, but it's true.

I want the ninth item from the second row on the third layer of the
eighth box from the left, fourth from this end. That's five dimensions
right there, and I haven't even told you which level of boxes I want
yet, or from which aisle of which store-room in which warehouse.

There's more to visualisation than how many lines you can imagine at
right angles to each other.

[Malcolm McLean]

Post by Richard Heathfield

Post by Malcolm McLean
And of course you can only visualise three dimensions.

I can visualise more than three dimensions. Sorry, Malcolm, but it's true.
I want the ninth item from the second row on the third layer of the
eighth box from the left, fourth from this end. That's five dimensions
right there, and I haven't even told you which level of boxes I want
yet, or from which aisle of which store-room in which warehouse.
There's more to visualisation than how many lines you can imagine at
right angles to each other.

There is some truth in that.
We can nest arrays deeper than three and still have a comprehensible address
Universe,Milky Way, Spiral Arm, Solar System, Earth, UK, Berkshire, Windsor,
Eton College, College, Upper dorm, Bed 5, Shelves,

Now close your eyes, and give me the rest of the directions to your item.

[Richard Heathfield]

Post by Malcolm McLean

Post by Richard Heathfield

Post by Malcolm McLean
And of course you can only visualise three dimensions.

I can visualise more than three dimensions. Sorry, Malcolm, but it's true.
I want the ninth item from the second row on the third layer of the
eighth box from the left, fourth from this end. That's five dimensions
right there, and I haven't even told you which level of boxes I want
yet, or from which aisle of which store-room in which warehouse.
There's more to visualisation than how many lines you can imagine at
right angles to each other.

There is some truth in that.
We can nest arrays deeper than three and still have a comprehensible address
Universe,Milky Way, Spiral Arm, Solar System, Earth, UK, Berkshire, Windsor,
Eton College, College, Upper dorm, Bed 5, Shelves,
Now close your eyes, and give me the rest of the directions to your item.

seventh level of the sixth ailse of the sixteenth storeroom along in the
ninth warehouse.

Damn, I'm good! (Yes, that was typed with my eyes firmly closed. I
messed up /one/ word. Sorry about that.)

[Siri Cruz]

Post by Richard Heathfield

Post by Malcolm McLean
There is some truth in that.
We can nest arrays deeper than three and still have a comprehensible address
Universe,Milky Way, Spiral Arm, Solar System, Earth, UK, Berkshire, Windsor,
Eton College, College, Upper dorm, Bed 5, Shelves,
Now close your eyes, and give me the rest of the directions to your item.

seventh level of the sixth ailse of the sixteenth storeroom along in the
ninth warehouse.

The Doctor giving Leela directions through the Tardis but she always ends up at
the pool.

[s***@casperkitty.com]

Post by Siri Cruz
Don't. There's no penalty for parenthesising more than strictly necessary.

An advantage of using extra parentheses is that they show not only what the
compiler will think the code means, but also what the author thought the code
means. Someone who is reading code might know enough about the rules to know
that the compiler will understand that "x<<y + z" means "x << (y+z)", but may
have a harder time figuring out whether the author understood that it meant
that.

If I were designing the next evolution of C, I would deprecate some of the
precedence rules so that expressions like the above would require use of
parentheses in "new" code. Compilers would still be required to be able to
process the existing code, but would be strongly encouraged to provide
an option to squawk at it (many compilers already have such an option; the
only difference would be that its existence would be an "official"
recommendation).

[crankypuss]

Post by Siri Cruz

Post by Udyant Wig
I am looking at the table of operator precedence and associativity
rules in Harbison and Steele, and I am wondering how (if?) I should
go about memorizing it, beside writing it out by hand over some days.

Don't. There's no penalty for parenthesising more than strictly necessary.

What is strictly necessary for the compiler to parse it, and what is
strictly necessary for a human to understand it, when he's the guy in
the barrel to fix it, both are imo absolutely necessary, unless you want
to figure it out again every time it doesn't work, or when you want to
modify it to do something else, in which case you might as well just sit
there and do it by hand, instead of using the computer to do the work.

[Not sure if that's parseable by a human, it may be a write-only
comment, LOL]

IOW, screw the compiler, write it so the next guy can understand it,
even if the next guy is dumber than you, or especially if it's you after
you've forgotten what it does.

[Siri Cruz]

Post by crankypuss

Post by Siri Cruz

Post by Udyant Wig
I am looking at the table of operator precedence and associativity
rules in Harbison and Steele, and I am wondering how (if?) I should
go about memorizing it, beside writing it out by hand over some days.

Don't. There's no penalty for parenthesising more than strictly necessary.

What is strictly necessary for the compiler to parse it, and what is
strictly necessary for a human to understand it, when he's the guy in
the barrel to fix it, both are imo absolutely necessary, unless you want

Either/both.

[Eric Sosman]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

Whenever in the slightest doubt, use parentheses.

I've been writing C for close to forty years, on and off, and
still haven't bothered to memorize all the operator precedences.
The really common ones, sure: multiply binds more tightly than add,
assignment binds more loosely than just about anything, and so on.
But keeping track of whether ^ precedes << is just not worth my
attention: If I need to use both, I'll use parentheses.

(Part of my disinclination to memorize the oddball cases is
that at the time I was first learning C I was also programming in
about three other languages, whose precedence rules sometimes
differed from those C uses for analogous operators. The chance
that I'd apply a C rule while writing PL/1 or a Pascal rule while
writing C was simply too great, so I came down in favor of being
painfully explicit. This "failing" has served me well.)

Remember, too, that even if you memorize all the operator
interactions perfectly, the next person who reads your code may
not understand them quite as well as you do. You may omit parens
because you know how || and && relate, but if he misunderstands
your meaning -- and maybe introduces a bug while mis-maintaining
what he mis-understood -- your terseness has not advanced the
overall cause much. It works the other way, too: I've debugged
cases where it wasn't at all clear whether the original coder got
it right or wrong (in one instance I tracked down the original
coder and even he couldn't tell me what he'd meant).

Learn the basics: +,-,*,/,%,=,==, and maybe a few more, and
expect pretty much everyone to share your knowledge. For anything
else -- well LISP programmers haven't *quite* used up all the
parentheses in the world, and you can still claim a few.

[Keith Thompson]

Post by Eric Sosman

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

Whenever in the slightest doubt, use parentheses.

I wouldn't go quite that far. I'd say you should use parentheses when
you're in *reasonable* doubt.

I know that && binds more tightly than ||, but I'd probably use
parentheses for `(a && b) || (c && d)`. But I wouldn't bother for
`a == b + c` or `a == b || c == d`.

I suppose the question is what constitutes "reasonable" doubt.

[...]

Post by Eric Sosman
Learn the basics: +,-,*,/,%,=,==, and maybe a few more, and
expect pretty much everyone to share your knowledge. For anything
else -- well LISP programmers haven't *quite* used up all the
parentheses in the world, and you can still claim a few.

Agreed.

[Jorgen Grahn]

Post by Keith Thompson

Post by Eric Sosman

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

Whenever in the slightest doubt, use parentheses.

I wouldn't go quite that far. I'd say you should use parentheses when
you're in *reasonable* doubt.
I know that && binds more tightly than ||, but I'd probably use
parentheses for `(a && b) || (c && d)`. But I wouldn't bother for
`a == b + c` or `a == b || c == d`.

Same here.

I also use parentheses liberally whenever |, & and << are involved,
because my intuition for those operators is a bit off.

Post by Keith Thompson
I suppose the question is what constitutes "reasonable" doubt.

I /think/ this is an area where C programmers agree, more or less.
So my advice would be to study a lot of existing code.

/Jorgen

[Eric Sosman]

Post by Jorgen Grahn
[...]
I also use parentheses liberally whenever |, & and << are involved,
because my intuition for those operators is a bit off.

Perhaps it's not your intuition, but C itself. One fairly
respectable commentator calls this part of the precedence hierarchy
an "infelicity," and explains the historical baggage that led to it:

http://heim.ifi.uio.no/~inf2270/programmer/historien-om-C.pdf

... page 8, under the heading "Neonatal C."

(By the way, in connection with another current thread: The
same paper says that Unix was originally written in assembly
language for the PDP-7, before C existed. Assertions that Unix
was the first O/S not written in assembly are therefore even
more dubious than might be imagined. Ibid, page 2.)

[s***@casperkitty.com]

Post by Eric Sosman
Perhaps it's not your intuition, but C itself. One fairly
respectable commentator calls this part of the precedence hierarchy
http://heim.ifi.uio.no/~inf2270/programmer/historien-om-C.pdf
... page 8, under the heading "Neonatal C."

Speaking of "infelicity", I would regard as infelicity the decision to say
that "&&" and "||" always return zero or one, rather than saying that
(x && y) should be (x ? y : 0) and (x || y) should be (x ? x : y) [but with
x only being evaluated once in the latter case]. I don't know whether any
language had ever had operators with the latter meanings, but they would have
allowed simpler generation of efficient code in many situations at both the
source-code and machine-code levels, and I can't think of many situations in
which coercing x and y to 0 and 1 is helpful. If code needs x to hold a zero
value if y and z are both zero, and a non-zero value if either is non-zero,
giving "x = y || z;" its present meaning would require a compiler to generate
something like:

mov r0,#0
load r1,[x]
jnz _nonzero
load r1,[y]
jz _zero
_nonzero:
mov r0,#1
_zero:
mov [y],x

rather than

load r0,[x]
jnz _nonzero
load r0,[y]

Still, if no other language had anything like "&&" and "||" I'd consider
them a useful invention even if they're not as good as they could be.

Post by Eric Sosman
(By the way, in connection with another current thread: The
same paper says that Unix was originally written in assembly
language for the PDP-7, before C existed. Assertions that Unix
was the first O/S not written in assembly are therefore even
more dubious than might be imagined. Ibid, page 2.)

What was the first operating system to have, say, 90% of its code ported into
something other than assembly language?

[Ben Bacarisse]

Post by s***@casperkitty.com

Post by Eric Sosman
Perhaps it's not your intuition, but C itself. One fairly
respectable commentator calls this part of the precedence hierarchy
http://heim.ifi.uio.no/~inf2270/programmer/historien-om-C.pdf
... page 8, under the heading "Neonatal C."

Speaking of "infelicity", I would regard as infelicity the decision to say
that "&&" and "||" always return zero or one, rather than saying that
(x && y) should be (x ? y : 0) and (x || y) should be (x ? x : y) [but with
x only being evaluated once in the latter case]. I don't know whether any
language had ever had operators with the latter meanings,

ECMAScript ("JavaScript"), Perl and Python come to mind (though Python
spells the operators "and" and "or").

<snip>

[Keith Thompson]

***@casperkitty.com writes:
[...]

Post by s***@casperkitty.com
Speaking of "infelicity", I would regard as infelicity the decision to say
that "&&" and "||" always return zero or one, rather than saying that
(x && y) should be (x ? y : 0) and (x || y) should be (x ? x : y) [but with
x only being evaluated once in the latter case]. I don't know whether any
language had ever had operators with the latter meanings, but they would have
allowed simpler generation of efficient code in many situations at both the
source-code and machine-code levels, and I can't think of many situations in
which coercing x and y to 0 and 1 is helpful.

[...]

Perl's && and || operators work that way. The way the Perl
documentation (`perldoc perlop`) describes it is that they return
the last value evaluated. (Perl treats 0 and some other values as
false, so it's a little different from what you suggest for C.)

[Ken Brody]

Post by Eric Sosman

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

Whenever in the slightest doubt, use parentheses.
I've been writing C for close to forty years, on and off, and
still haven't bothered to memorize all the operator precedences.
The really common ones, sure: multiply binds more tightly than add,
assignment binds more loosely than just about anything, and so on.
But keeping track of whether ^ precedes << is just not worth my
attention: If I need to use both, I'll use parentheses.

[...]

Ditto. (Though I only have about 35 years experience.)

Parentheses also help someone reading your code, if for no other reason than
it says "this is what I meant, and I'm not depending on operator precedence
for those less-often used operators".

[Stefan Ram]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

The first step is to simplify: We ignore »,«, »=«, and »?:« and
group the remaining operators into three groups:

First the »arithmetical operators« (in a very wide sense of the
word »arithmetics«) "Ar": »++«, »*«, »+«, »<<«, ....
They have the highest priority.

The come the »Comparison operators« "Co": »<«, »==«, ...
They have a middle priority.

Finally, the »logical operators« "Lo": »&«, »&&«, ... .
They have the lowest ("Lo"!) priority.

Only after having worked with this for one year, we will then
add refinements to out memory that further subdivide the groups.

Mnemonics: »ArCoLo«.

One can remember it this way: One wants to write

a + 2 < x && x < a + 7

without parentheses. Therefore, »+« must have higher precedence
than »<«, which must have higher precendence than »&&«. Therefore,
arithmetics > comparison > logic, »ArCoLo«.

[Stephen Sprunk]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity
rules in Harbison and Steele, and I am wondering how (if?) I should
go about memorizing it, beside writing it out by hand over some
days.

If you need to look it up, just use parentheses instead.

S

[BartC]

Post by Stephen Sprunk

Post by Udyant Wig
I am looking at the table of operator precedence and associativity
rules in Harbison and Steele, and I am wondering how (if?) I should
go about memorizing it, beside writing it out by hand over some
days.

If you need to look it up, just use parentheses instead.

What was the point of so many levels then?

[Malcolm McLean]

Post by BartC

Post by Stephen Sprunk

Post by Udyant Wig
I am looking at the table of operator precedence and associativity
rules in Harbison and Steele, and I am wondering how (if?) I should
go about memorizing it, beside writing it out by hand over some
days.

If you need to look it up, just use parentheses instead.

What was the point of so many levels then?

If the operators aren't associative :- so a + b - c = (a + b) - c or a + (b -c)
but not a << b + c : (a << b) +c won't equal a << (b +c) in the general case,
you have to write the expression parser somehow.

The options are left to right or levels of precedence.

[Stephen Sprunk]

Post by BartC

Post by Stephen Sprunk

Post by Udyant Wig
I am looking at the table of operator precedence and
associativity rules in Harbison and Steele, and I am wondering
how (if?) I should go about memorizing it, beside writing it out
by hand over some days.

If you need to look it up, just use parentheses instead.

What was the point of so many levels then?

Contrary to what some posters here believe, ANSI/ISO _did_ try to codify
behavior wherever possible, and apparently implementations all agreed in
this case, so that became the standard. This meant any existing code
that _did_ depend on that behavior, rather than just using parentheses,
would continue to work.

S

[s***@casperkitty.com]

Post by Stephen Sprunk
Contrary to what some posters here believe, ANSI/ISO _did_ try to codify
behavior wherever possible, and apparently implementations all agreed in
this case, so that became the standard. This meant any existing code
that _did_ depend on that behavior, rather than just using parentheses,
would continue to work.

I suspect the decision to have unsigned short types promote as signed longer
types was also motivated by the fact that such promotions wouldn't prevent
compilers from making things work. Given code like:

unsigned_small_type x=.., y=..; // Half the size of "int"
unsigned int z=x*y;

I don't think there was any intention that compilers for any "normal"
architectures should do anything other than treat the code as
"z=(unsigned)x*y". The Standard doesn't mandate such treatment, but I
suspect that's because there was no imagined reason for compilers on
normal architectures to do anything else.

[Jerry Stuckle]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

Don't memorize it. Rather, understand what it is saying. It all makes
sense once you do, but will take practice. Keep a copy handy until you
do, and always use parens when you're unsure.

[crankypuss]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity
rules in Harbison and Steele, and I am wondering how (if?) I should go
about memorizing it, beside writing it out by hand over some days.

Use it. Make up a paper cheat-sheet, or set up a shortcut in your
browser, or paste it into a text file, whatever it takes to make it easy
to look something up. Then use it.

[Philip Lantz]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

I photocopied the page in K&R and cut out the table and posted it on my
wall next to my monitor about 30 years ago. I still have that original
photocopy, and I still keep it on the wall, and I still refer to it on
rare occasions.

I agree with the other comments that suggest not worrying about it too
much. But there is one precedence relationship that I think everyone
should remember and use properly, and that is the relationship between
== and &&. This is one of the most commonly used things in the language:
if (x == a && y == c)
and no one should need that to be parenthesized to understand it at a
glance. And of course that applies to || and the other relational operators.

One that took me the longest to learn was that the relationship between
<< and | is like that of * and +. But I hardly use that information
because in most cases I still parenthesize it to be more readable.
And I still don't know (or care) about the relative precedence of
| and ^.

[John Bode]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.
--
Udyant Wig
Software projects: https://bitbucket.org/udyant
Poetry: http://www.writing.com/main/portfolio/view/frosthrone

This is why reference manuals exist. There are 16 distinct levels of
precedence, which is more than most people can accurately commit
to memory. Your best option is to photocopy that page from H&S and tape
it to the wall next to your desk.

Over time you'll internalize most of the rules through sheer repetition.
When in doubt, use parentheses.

[boon]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

There are cases which are easy to memorize especially for operators with
the higher precedence :

. (direct selection) and -> (indirect selection) have higher precedence
than & (address of) and * (indirection).

So, you can safely always write :

&p.q in place of &(p.q)

same for * in place of &, and -> in place of .

About == != < > <= >=, they have higher precedence than || && (and
others)

So you can safely write :

A == B || C != D in place of (A == B) || (C != D)



Furthemore note that when operators have the same precedence, they all
have the same associativity (left or right).

[Tim Rentsch]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity
rules in Harbison and Steele, and I am wondering how (if?) I
should go about memorizing it, beside writing it out by hand over
some days.

I have a somewhat different answer for this than some of the
other responses you've gotten.

I agree with the recommendation to make a copy of the table, and
keep it handy, near your display or where ever it might be
convenient.

I also agree with the recommendation that whenever you are not
sure which way a particular expression goes (or would go, if it
hasn't been written yet) that you look it up. However, /before/
you look it up, take a moment and write down which way you think
it goes in the absence of any extra parentheses. Doing that
will help you to better remember in the future, whether your
guess is right or wrong. Also it serves to monitor how well
you are doing internalizing the different relationships.

A commonly made suggestion is to put in parentheses (that may be
redundant) whenever you are unsure or you think the next person
to look at the code might be confused. I have a different
recommendation: never(*) use redundant parentheses. If you are
unsure, look it up before committing to code. If you think the
next person (including yourself) might be unsure or confused,
indicate the relative precedence in question using spaces rather
than parentheses, as for example, instead of (x+y)<<7, write:

x+y << 7

Following this rule has several benefits: it helps you remember;
it helps your co-workers remember; it shows both what the
relative precedences are and that you are aware what they are,
and that they may be confusing to some people so it is important
to disambiguate. Furthermore if what you think is wrong that is
apparent in how the expression is written. In contrast, writing
(x+y)<<7 doesn't help anyone remember, it leaves in doubt the
question of why the parentheses were added, and it keeps new
people in the dark about what the rules are. Simply adding
parentheses whenever you are unsure does a disservice to
yourself, to your co-workers, and to those in the process of
learning C. If you are in doubt, look it up and remove the
doubt; then write the code to convey that knowledge to other
readers. The result is better for you, better for them, and can
be mechanically checked to make sure the assumptions match what
really happens.

Anyone following these recommendations should find fairly soon
they have learned how to answer most of the operator precedence
questions that commonly come up, without having to make any
special or concerted effort.


(*) On very rare occasions an extra set of parentheses might
be added for reasons other than precedence - for example, to
give a symmetric presentation. The point is not to add extra
parentheses just because an expression "might be confusing"
without them. Also, using parentheses inside macro definitions
needs to recognize a different and more elaborate set of
concerns and motivations.

[luser droog]

Post by Udyant Wig
I am looking at the table of operator precedence and associativity rules
in Harbison and Steele, and I am wondering how (if?) I should go about
memorizing it, beside writing it out by hand over some days.

Here's my contribution, from 09. Trying to convert the table into a mnemonic.
https://groups.google.com/d/msg/comp.lang.c/efPI5ASnIjE/OIzL_PU1yHgJ