mnemonic

A

aarklon

Hi all,

Is there any mnemonic for remembering C precedence rules????

I have just coined the word TUBSREBLCAC

where T --- top level operators
U ---- unary operators
B ----- binary operators
S ------ shift operators
R------- relational operators
E ------ equality operators
B ------- bitwise operators
L ------- logical operators
C ----- conditional operators
A ----- assignment operators
C ------ comma operator

how good is this mnemonic

or is there any simple mnemonic such as

"How I want a sweetened drink of course after the heavy lectures
involving quantum mechanics" which is mainly used by math pros for
remembering Pi value(3.14195265358979)
 
V

vipvipvipvipvip.ru

Operator precedence is nothing like pi.
Practice, and it will come naturally which is higher/lower.
 
J

Julienne Walker

Hi all,

Is there any mnemonic for remembering C precedence rules????

Use parentheses and it's impossible to forget the precedence
rules. :)
I have just coined the word TUBSREBLCAC

where T --- top level operators
U ---- unary operators
B ----- binary operators
S ------ shift operators
R------- relational operators
E ------ equality operators
B ------- bitwise operators
L ------- logical operators
C ----- conditional operators
A ----- assignment operators
C ------ comma operator

how good is this mnemonic

I think I'll just stick to parens and not even try to remember that
mess of characters.

-Jul
 
V

vipvipvipvipvip.ru

Parentheses can be annoying and useless in code.
The solution is to learn operator precedence.
 
J

Julienne Walker

Parentheses can be annoying and useless in code.

They can be, if you use them abusively. On the other hand, *lack* of
parentheses can be annoying and useless in code for the same reason.
The solution is to learn operator precedence.

Perhaps *you* have perfect memory, but *I* don't. I'd rather remember
a simple guideline than a slew of rules, because to be perfectly
frank, I have better things to spend my few remaining brain cells
on. :)
 
E

Eric Sosman

Parentheses can be annoying and useless in code.
The solution is to learn operator precedence.

... and to teach the rules to everyone who will ever
read your code, which I think you'll agree is a bit of
a chore.

Even if Joe Coder knows the precedence rules perfectly
and can parse

if ( a && b | c && d )

without blinking, he may still wonder whether *you* were
entirely familiar with the rules: He knows perfectly well
what's being tested, but how can he be sure it's what you
intended to test? Did you really mean what you wrote, or
was it a typo? A few parentheses to set his mind at rest
are by no means "useless."

For myself, there's also the problem that C's rules
clash with those of some other languages I use or have
used. I recall a time, some years ago, when I worked in
C and Pascal on one project (the data aquisition piece
was in C, and the analysis in Pascal). The conflicting
precedence rules kept tripping me up: I'd write C as if
Pascal's rules applied, or the other way around. So I
formed the habit of using "unnecessary" parentheses -- in
moderation -- to make my intent clear both to the compiler
and to myself. And I've never regretted it.
 
S

Serve Lau

Parentheses can be annoying and useless in code.
The solution is to learn operator precedence.

I use the parentheses rule too when in doubt, but when they become too
"annoying" in certain expression, only then I look up the rules in a book or
something to make that expression clearer. No need remembering the
precedence rules by heart
 
B

Ben Pfaff

Eric Sosman said:
Even if Joe Coder knows the precedence rules perfectly
and can parse

if ( a && b | c && d )

without blinking, he may still wonder whether *you* were
entirely familiar with the rules:

With or without additional parentheses, I'd be inclined to think
that | should be || in the above. (In context, it would probably
be obvious whether | was correct.)
 
A

Al Balmer

I use the parentheses rule too when in doubt, but when they become too
"annoying" in certain expression, only then I look up the rules in a book or
something to make that expression clearer. No need remembering the
precedence rules by heart
In such cases, you'd probably be better off studying your code to see
why it appears so complex.

“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.” – Brian W. Kernighan
 
E

Eric Sosman

Ben Pfaff wrote On 11/01/07 17:48,:
With or without additional parentheses, I'd be inclined to think
that | should be || in the above. (In context, it would probably
be obvious whether | was correct.)

My point is that one would not need to rely on one's
inclinations or suppositions if the author had written

if ( a && (b | c) && d )
or even
if ( a && (b | c) != 0 && d )

As for obviousness: Yes, you can usually figure out
what the code *should* mean, but sometimes the project
becomes as intricate as a CSI episode (and less exciting).
Whenever I've had to spend time deciding that something
was really intended and not a typo, I've added parentheses
or a zero comparison or something of the kind so that the
next person won't have to sleuth it out all over again (and
maybe get it wrong).

Two kinds of readers peruse source code: computers and
people, and the latter are the more important readership.
 
R

Richard

Al Balmer said:
In such cases, you'd probably be better off studying your code to see
why it appears so complex.

“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.†– Brian W. Kernighan

This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. Especially when combined with HW break points and expression
watches.

I have debugged a LOT of large systems and fixed them without having the
need to understand the entire system.
 
R

Richard Tobin

Is there any mnemonic for remembering C precedence rules????

If you need a mnemonic, you shouldn't be trying to do it.

If you have trouble remembering the order, use parentheses.

Some rules are obvious: && and || bind less strongly than comparison
operators, which in turn bind less strongly than arithmetic operators,
because otherwise the 90% case of conditions like if(a == b+c) would
need extra parentheses. Assignment binds weakly for the same reason.
You may be able to find convincing explanations for some of the others,
but if you can't see why addition binds more strongly than shift why
bother? Quite likely your readers can't either.

-- Richard
 
B

Ben Pfaff

Eric Sosman said:
Ben Pfaff wrote On 11/01/07 17:48,:

My point is that one would not need to rely on one's
inclinations or suppositions if the author had written

if ( a && (b | c) && d )
or even
if ( a && (b | c) != 0 && d )

To me, your article quoted above raises two points: precedence
and correct choice of operators. I chose to comment on the
latter. In my opinion, the point about precedence could have
been made just as effectively using || instead of |.
As for obviousness: Yes, you can usually figure out
what the code *should* mean, but sometimes the project
becomes as intricate as a CSI episode (and less exciting).
Whenever I've had to spend time deciding that something
was really intended and not a typo, I've added parentheses
or a zero comparison or something of the kind so that the
next person won't have to sleuth it out all over again (and
maybe get it wrong).

Two kinds of readers peruse source code: computers and
people, and the latter are the more important readership.

I heartily agree.
 
C

CBFalconer

Julienne said:
They can be, if you use them abusively. On the other hand, *lack*
of parentheses can be annoying and useless in code for the same
reason.


Perhaps *you* have perfect memory, but *I* don't. I'd rather
remember a simple guideline than a slew of rules, because to be
perfectly frank, I have better things to spend my few remaining
brain cells on. :)

I limit my precedence memory to: Multiplicative ops, additive ops,
relational ops. If anything further is needed, make it clear (and
sure) with the appropriate parentheses.

You'ld be surprised how many languages this serves!
 
E

Eric Sosman

Richard said:
Al Balmer said:
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.†– Brian W. Kernighan

This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. [...]

The only empirical study I'm aware of came to the opposite
conclusion. A bunch of computer science students were handed
an existing program and told to debug it. Half received the
program as originally written, half received the same program
minus all its comments. The comment-less group found more of
the bugs and found them faster. So much for documentation.

I think the experiment was described in "The Psychology of
Computer Programming," but I can't remember for sure. The authors
speculated that the comments led the readers down the same paths
of fallacious reasoning that the original code writers followed
when they wrote the bugs in the first place.
 
R

Richard

Eric Sosman said:
Richard said:
Al Balmer said:
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.†– Brian W. Kernighan

This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. [...]

The only empirical study I'm aware of came to the opposite
conclusion. A bunch of computer science students were handed
an existing program and told to debug it. Half received the
program as originally written, half received the same program
minus all its comments. The comment-less group found more of
the bugs and found them faster. So much for documentation.

I think the experiment was described in "The Psychology of
Computer Programming," but I can't remember for sure. The authors
speculated that the comments led the readers down the same paths
of fallacious reasoning that the original code writers followed
when they wrote the bugs in the first place.

Depends on your familiarity with the code and how well you know how to use
a debugger. Some people are just good at it - binary chop and gut
instinct.
 
T

Tim Brown

or is there any simple mnemonic such as

"How I want a sweetened drink of course after the heavy lectures
involving quantum mechanics" which is mainly used by math pros for
remembering Pi value(3.14195265358979)

woopsie!

your "sweetened drink" should be "drink sweetened" to make the pi value
come out correctly


Tim
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top