Clean living and

The precdence of ‘&’ in C/C++ just cost me another hour. It’s probably cost me a cumulative week of debugging time in the last quarter century.

Remember to brush your teeth, bathe regularly, chew with your mouth closed, and parenthesize your expressions.

This entry was posted in Uncategorized. Bookmark the permalink.

12 Responses to Clean living and

  1. norse says:

    Well said. Then again, I’d choose to lose a week my life to actual bug chasing over the months lost in process overhead…

  2. Tom says:

    But every single time it hurts so much when the light dawns that I *know* I’ll never be this stupid again, so long as I live I’ll remember that trap. What’s truly remarkable is that after so many instances I can still look honestly surprised each time…

  3. C'est moi says:

    1) Dear norse, what processing overhead are you talking about? Parenthesis is merely used to alter an expressions precedence and any extra cycles consumed are done so at compile-time and not run-time. As for deferring your time to execution time, all I have to say is that either you’re living in the third world or you don’t know how much your time costs.

    2) I parenthesise everything I’m not willing to place a months income on should I be asked just how sure I am I know what the parse tree will look like. I will, however, never plumb the deepest depths of ignorance and stick parentheses around the expression that follows the “return” keyword. It is not right, it is not proper, it is just not done. A statement is a statement and an expression is an expression….. actually no, an expression can be a statement as long as it’s followed by a semicolon (K&R 1988, Appendix A, p236, grammar rule “expression-statement”.)

    3) Prolog offers — the ISO standard actually mandates — mechanisms where you can query the precedence of any operator (current_op/3) and even print terms (that’s expressions to non-Prologians) using infix operators in a unambiguous Polish (prefix) notation (display/[1,2], write/[3,4]). In an interactive language this is really useful. No doubt other languages will be doing the same these days.

  4. Adam Robinson says:

    This is why I always parenthesise everything. A slight pain, but it means everything always does exactly what I specify, and anyone else coming from some other language, can see exactly what I specified.

    On the other hand, its probably contributed to me getting RSI :p I do a lot of maths code!

  5. Grout says:

    Please parenthesize everything! I will then know you don’t know the language.

    • Kevin says:

      Better for people like Adam to be honest and considerate. l33t coding style can only go so far when other people are depending on being able to build on and maintain your work.

    • Ce'st Moi says:

      Dear Grout,
      Please reason abductively! I will then know that you put your faith in unsound rules of inference.

      Mercy buckets.
      C’est Moi.

    • Ewan says:

      As a rule, I generally spell things out with parentheses, as do my colleagues. When you’re trying to grok something at 3am, every little helps.

    • Nate says:

      I always assume the person who will touch the code after me won’t know the language as well as I do. Parentheses are my way of speaking really slowly for that poor fool.

  6. Wally says:

    To parenthesise everything is the stuff of religious wars in software land.

    I parenthesise everything because I have only been writing C code for 25 years but I can never remember the operator precedence rules (and doubly so when mixing arithmetic and logical operators).

    So parenthesis is my way of spelling out exactly what I want with no time wasted looking things up, assuming, or otherwise futzing around.

    I’m paid to deliver a solution that works, not a piece of code with the smallest number of bytes of source code.

    Those who say “understand the language” are really saying “see, I’m so much smarter than you”. A fine piece of arrogance which will eventually come back to haunt.

  7. Tomsci says:

    My rule of thumb is to start parenthesising if I’ve got more than one type of logical operator (in addition to ==) or if I have any of the weirder operators in general, bracket EVERYTHING.

    if (x == 2 && y == 3)
    if (x == 2 && (y == 3 || z == 4))
    if ((x&1) || (y ==2))

    The biggest point is, I don’t care what the precedence of operator(randomPunctuation) is, and it doesn’t make me a better engineer to be able to recall the ANSI precedence table out the back of one of my old textbooks. All I need to remember is the simple cases that work, and anything else should be explicit in the interest of preserving people’s sanity. In the past I’ve had to prove that adding brackets to an expression fixed a bug (process process…) and what I kept thinking was “I can’t believe I’m having to justify adding brackets!”. I mean, no one else could tell me what it was supposed to do, let alone what it actually did, so…

  8. C'est moi says:

    Today’s misadventure with C.

    I wanted to toggle a flag (I’m writing a keyboard driver and I want to keep track of the status of the caps lock). So I want

    caps_lock = !caps_lock;

    whenever the caps lock key is pressed. For some strange reason I actually write it as

    caps_lock != caps_lock;

    and it compiles of course — it’s a valid expression.

    In other news, I still don’t like how ASCII is so non-American keyboard unfriendly. How do you get ASCII 128 (decimal) via ~^@ (META/ALT NUL) when the @ character cannot be produced without using the AltGr key and, here’s the kicker, I’m, getting the same scan code for both Alt keys. It means theres no way to tell if it’s ASCII 128 or ASCII 0 (NUL). Similar joy with $, [, and, ]. So very unfair and time consuming.

Comments are closed.