Post by Udyant WigI 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.