mnemonic

Discussion in 'C Programming' started by aarklon@gmail.com, Nov 1, 2007.

  1. Guest

    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)
     
    , Nov 1, 2007
    #1
    1. Advertising

  2. Guest

    Operator precedence is nothing like pi.
    Practice, and it will come naturally which is higher/lower.
     
    , Nov 1, 2007
    #2
    1. Advertising

  3. Ian Collins Guest

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

    Context?

    --
    Ian Collins.
     
    Ian Collins, Nov 1, 2007
    #3
  4. Al Balmer Guest

    On Thu, 01 Nov 2007 19:18:41 -0000, wrote:

    >Hi all,
    >
    >Is there any mnemonic for remembering C precedence rules????


    Here's the one I use:
    "If in doubt, use parentheses."

    --
    Al Balmer
    Sun City, AZ
     
    Al Balmer, Nov 1, 2007
    #4
  5. On Nov 1, 3:18 pm, wrote:
    > 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
     
    Julienne Walker, Nov 1, 2007
    #5
  6. Guest

    Parentheses can be annoying and useless in code.
    The solution is to learn operator precedence.
     
    , Nov 1, 2007
    #6
  7. On Nov 1, 4:43 pm, wrote:
    > 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. :)
     
    Julienne Walker, Nov 1, 2007
    #7
  8. Eric Sosman Guest

    wrote On 11/01/07 16:43,:
    > 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.

    --
     
    Eric Sosman, Nov 1, 2007
    #8
  9. Serve Lau Guest

    <> wrote in message
    news:...
    > 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
     
    Serve Lau, Nov 1, 2007
    #9
  10. [comp.lang.c] Ian Collins <> wrote:

    > wrote:
    >> Operator precedence is nothing like pi.


    > Context?


    >> Alice wrote:


    >>> "One day, I was at the comp.lang.c tea party and someone in a funny
    >>> hat asked me 'How is operator precedence like pi?', and I was
    >>> perplexed. Can anyone help?"


    (I didn't see the context either.)

    --
    C. Benson Manica | I appreciate all corrections, polite or otherwise.
    cbmanica(at)gmail.com |
    ----------------------| I do not currently read any posts posted through
    sdf.lonestar.org | Google groups, due to rampant unchecked spam.
     
    Christopher Benson-Manica, Nov 1, 2007
    #10
  11. Ben Pfaff Guest

    Eric Sosman <> writes:

    > 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.)
    --
    "Am I missing something?"
    --Dan Pop
     
    Ben Pfaff, Nov 1, 2007
    #11
  12. Al Balmer Guest

    On Thu, 1 Nov 2007 22:28:13 +0100, "Serve Lau" <> wrote:

    >
    ><> wrote in message
    >news:...
    >> 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
    >

    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

    --
    Al Balmer
    Sun City, AZ
     
    Al Balmer, Nov 1, 2007
    #12
  13. Eric Sosman Guest

    Ben Pfaff wrote On 11/01/07 17:48,:
    > Eric Sosman <> writes:
    >
    >
    >> 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.)


    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.

    --
     
    Eric Sosman, Nov 1, 2007
    #13
  14. Richard Guest

    Al Balmer <> writes:

    > On Thu, 1 Nov 2007 22:28:13 +0100, "Serve Lau" <> wrote:
    >
    >>
    >><> wrote in message
    >>news:...
    >>> 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
    >>

    > 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.
     
    Richard, Nov 1, 2007
    #14
  15. In article <>,
    <> wrote:

    >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
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Nov 1, 2007
    #15
  16. Ben Pfaff Guest

    Eric Sosman <> writes:

    > Ben Pfaff wrote On 11/01/07 17:48,:
    >> Eric Sosman <> writes:
    >>
    >>
    >>> 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.)

    >
    > 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.
    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
    =b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
    2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
     
    Ben Pfaff, Nov 1, 2007
    #16
  17. CBFalconer Guest

    Julienne Walker wrote:
    > wrote:
    >
    >> 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. :)


    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!

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Nov 2, 2007
    #17
  18. Eric Sosman Guest

    Richard wrote:
    > Al Balmer <> writes:
    > [...]
    >> “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.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Nov 2, 2007
    #18
  19. Richard Guest

    Eric Sosman <> writes:

    > Richard wrote:
    >> Al Balmer <> writes:
    >> [...]
    >>> “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.
     
    Richard, Nov 2, 2007
    #19
  20. Tim Brown Guest

    wrote:
    >
    > 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
     
    Tim Brown, Nov 2, 2007
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jacob navia

    Mnemonic

    jacob navia, Nov 3, 2007, in forum: C Programming
    Replies:
    40
    Views:
    1,581
    Mark McIntyre
    Nov 10, 2007
  2. subwiz
    Replies:
    1
    Views:
    351
    John B. Matthews
    Sep 19, 2008
  3. J Krugman
    Replies:
    2
    Views:
    130
    Ben Morrow
    May 19, 2004
Loading...

Share This Page