• Hans (unregistered) in reply to Coyne
    Coyne:
    Gerald:
    substract 1 and take the absolute. then suddenly the values are the right way round

    Much easier and even more confusing if you subtract from 1:

        (1 - var)

    But the real WTF here is... (drumroll)

     People doing math operations on enums.

    It is bad enough that you feel you must be able to treat it like a truth value and cast it to bool, but doing this sort of stupid math tricks makes it far harder to ever do any sort of meaningful refactoring on it. Which is presumably why this stupid piece of code still lives today.

    If you wanted to do math with it, by all means define the values as constants:

    const int yes = 0; const int not = 1;

    Now you can do all the math you want. Or if you really, really want an enum, at least give some proper clue that these values are supposed to be unchanging because someone thought it was cute to use them as integers:

    // Don't change this, all sorts of calculations depend on // these values.

    enum { yes = 0, not = 1, };

    But don't just write a bunch of symbols in an enum list and then do funny calculations with them. It really, really hurts maintainability.

  • David (unregistered) in reply to jjacksonRIAB

    Ugh. No.

    (var == Yes)

    Even !var would be better than (1 - var); if you're using an integer like a boolean, treat it like a boolean, not like an integer. But better still, don't rely on ordinals of enum constants.

  • Fatt Moley (unregistered) in reply to iMalc
    iMalc:
    mattmoss:
    Does that mean two wrongs make a right? Hmm...

    Not + Not => 2

    Guess naught.

    Ah but two right's make a right, right? Yes + Yes => Yes!

    In England, two rights makes a U-Turn.

  • Wild Thing (unregistered) in reply to Phyzz

    That was ridiculously funny!

  • Wild Thing (unregistered) in reply to Phyzz
    Phyzz:
    iMalc:
    mattmoss:
    Does that mean two wrongs make a right? Hmm...

    Not + Not => 2

    Guess naught.

    Ah but two right's make a right, right? Yes + Yes => Yes!

    I'll have what that enum is having.

    Sorry, this is the one I was talking about...

    captcha: smile (yeah, sheepish)

  • Chris (unregistered)

    I've seen this exact same thing in code that I maintain. The spec says something like "the customer wants a combo box with the values Yes and No". The developer codes exactly what the customer asked for without stopping to think that maybe he can re-use a boolean for it. Duh.

  • nust v (unregistered)

    Albeit "Not" should be "No", isn't the pithiness around this whole notion of what something called 'Yes' should be in memory a little juvenile?

    Isn't the whole point of an enumeration like this to transcend the meaningless vernacular of numerical affirmatives and refutations?

    (I'm not an expert on debuggers but a smart one shouldn't have troubling recognizing an enumerated type value and representing the way the author did.)

    Actually, isn't it a little more critical to recognize the distinction between yes/no and true/false? If i ask you "Would you care for some coffee?" and you answered "FALSE" i would think you don't want coffee because you're a robot and robots don't like coffee. You probably want some hot resin to patch up your leak.

    Just saying, okay.

  • (cs)

    This is one of those cases where making the code more readable has made it less readable. a) 1 and 0 are good enough already b) Not is not as good as no. I'm not a C++ programmer; does C++ have anything like Java's typesafe enums? I like that Java feature because it's never possible to pass the wrong class of enum into a function.

    Oh, the Java equivalent of the badness of defining that enum is something I see pretty often in Java code:

    Boolean b = new Boolean(true);

    Boolean is one of those classes that should never had had a constructor. new Boolean() is just as bad as this enum is.

    Beverly Hills Mailboxes

  • captcha: (unregistered)

    enum { no = 0, yes, maybe, i_dont_know, can_you_repeat_the_question };

  • (cs) in reply to captcha:
    captcha::
    enum { no = 0, yes, maybe, i_dont_know, can_you_repeat_the_question };
    The funny thing is i_dont_know == yes | maybe...
  • Peccadillo (unregistered) in reply to Jno

    I thought about this this way:

    There are two possibilities

    1. Simon is telling the truth, and it is opposite day, or
    2. He's lying.

    If Simon is telling the truth, it is opposite day, in which case Mikoangelo is lying because the meaning of his statement is "It's not opposite day". Conversely, if Simon is lying, Mikoangelo is still lying because it's not opposite day.

    Now T-Money says it's not opposite day, which is true whether it actually is opposotie day or not.

  • Peccadillo (unregistered) in reply to Jno
    Jno:
    Zygo:
    T$:
    Mikoangelo:
    Simon:
    It's opposite day!

    Yes, it is.

    No it isn't. Now who's telling the truth, me or Mikoangelo?

    Mikoangelo, if I remember my logic puzzles correctly...

    Depends if you are Pukkas, Shilli-Shallas or WottaWoppas. If I was to ask Mikoangelo which tribe he belonged to, what would he say?

    http://mathforum.org/dr.math/faq/faq.liar.html

    Oops, my last post was in response to the above sub-thread.

Leave a comment on “Not the Most Thought Out Enumeration”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article