mnemonic

[Charlie Gordon]

Not that I know, but here are some thing that help me remember:

All the operators that "come after" bind the tightest. If you can't
remember this on it own, just think that a cast, despite being a very
high priority operator, can be used on a function call (or array
element) with no extra brackets: '(char *)function(...)'.

In maths, unary operators usually have high precedence and C follow
this. Thus all the prefix unary operators come next.

Most arithmetic tests don't need extra parentheses because the
relations (==, <, etc) bind more loosely than arithmetic.

Everyone know that * binds more tightly than +, so just remember that
&& and & are the Boolean and bit-wise analogues of multiplication
whereas || and | are the analogues of +. I.e. && binds tighter
than || and & beats |. (Many maths notations use AB or A×B to mean A
and B.)

While this is a good analogy, it may be misleading because & binds less than
+

Remembering that , is the lowest is also easy because , can replace ;
to turn a sequence into an expression (heck, it even looks like a
semicolon). It also mimics the way , behaves in a parameter list
(although of course *that* comma is quite another syntactic entity).

This covers the vast majority of common cases. I also like to
remember that you can assign a conditional ('index += up ? 1 : -1' is
my canonical example), but you can't shift by an arithmetic expression
('x >> (32 - bits)' requires the parentheses).

No, it does not: >> binds less than + and -, but it is certainly a good idea
to use parentheses to make your intent clear for both yourself and the next
person reading the code.

I hope this helps. The basic idea -- remembering what classic cases do
and do not need parentheses -- seems to me more valuable than rote
learning of the table.

Another useful advice is to turn on warnings your compiler might have to
flag common mistakes about operator precedence. gcc has an option for that,
I don't know if other compilers do.

 

[Charlie Gordon]

I'd say that about half of my bugs I find with printf. Another
half, I find with valgrind. Another 5% are made obvious with
"git bisect". The last 10%, I find with a traditional debugger.

My experience gives similar results.
I should also mention the 50% or more that are caught at typing time by
using proper editing tools with syntax coloring, automatic indentation,
brace balancing, completion... and the other 50% detected at code review
time.
But for reproducible crashes and endless loops, the debugger is indeed a
very effective tool.

 

[Ben Bacarisse]

While this is a good analogy, it may be misleading because & binds less than
+

I suppose it might. It helps only for the pairs * and +, && and ||, &
and |.

No, it does not: >> binds less than + and -, but it is certainly a good idea
to use parentheses to make your intent clear for both yourself and the next
person reading the code.

Good spot. Don't know where I got that from. For some reason I
always bracket these and that must have lodged in my mind as being
required, but of course it is not.

 

[Charlie Gordon]

One hardly has to be ancient. I am 46 and my first programs were
written on coding forms and posted to Dundee. The printout came back
the next week. Punching my own cards was came a year later. Of
course, interactive systems were available at the time, but they were
considered expensive compared to the batch systems.

I must say, an hourly turn round does alter ones attitude to typos and
bugs of all sorts. To link this to another thread, I was trilled when
interactive debuggers arrived, and bowled over by source-level
debugging, but the infatuation wore off after a few years. They have
their place, but all debugging ultimately happens in the brain even if
some of the data comes from a debugger.

My own experience is very similar to this. The 12-key card puncher seems
has been an effective tool to sharpen visual acuity.