• Lummox (unregistered) in reply to Tirinoarim

    The real WTF is that he needed a truth table to figure out that was the same as:

    return test;

    When you have boolean == boolean ? (boolean == boolean ? boolean : boolean) : (boolean == boolean ? boolean : boolean), then it's a pretty safe bet you're returning a boolean value, like the one you're comparing to true in the first place.

    I guess I'm not accounting for FILE_NOT_FOUND in my example though . . .

  • Rob (unregistered)

    The programmer who wrote this was stoned at the time. :)

    OK ok.. boolean .. got to return boolean... boolean, right! True or false! Right, true of false... true or false.. OK - if the variable is true.. test it again just to make sure.. If it false on the back up test, return false.. false.. false... oh yeah, it's a boolean. Damn I'm hungry..

  • (cs) in reply to Tirinoarim
    Tirinoarim:
    Of course theres the 3-value-boolean problem.

    In certain languages (gee thanks MickeySoft) a boolean can be true, false or null. In which case

    if (test) do(a) else do(b)

    does neither!

    You also don't get it do you. A boolean can only be true or false. A boolean variable can be true false or null, but it should always be safe to assume either true or false when presented with a null. If it can not be safely assumed, then you don't have a boolean, you have a tri-state enumeration. i.e. Shipped variable, if it is null you can safely assume false. Inspected variable, if null assume false. PackageReceived variable, if null assume unknown, this is a third state not handled by a boolean, so you now have an enumeration with three values, do not represent this with a boolean as it can not handle all potential values, as once you have three values, you may find more.

  • Joel (unregistered) in reply to cod3_complete
    cod3_complete:
    Sooooooooo true. I dump junk code on a regular basis when I find it. Unfortunately, other 'developers' I know of aren't so enlightned.
    This works fine, except when your project lead tends to blame all recently-found application bugs on the removal of old "working" code. On more than one occasion I've taken it upon myself to remove really ridiculous logic in code tangentially related to the bug I am fixing (or the feature I'm adding), only to have my boss call me into his office the next day and say "I see you changed all of this code that wasn't related to your assignment. Why did you do that? That code was working perfectly fine. Oh yeah, and there is a bug that I just noticed in testing this; you shouldn't have changed that."

    Even if I can prove that my changes didn't cause the bug (which they almost never have) he would get pissed off and instruct me to not make changes like that without clearing them with him first.

    It's just not worth the hassle of being harassed when you're in that situation.

    Fortunately, my boss has come to trust me a lot more and I am allowed a lot more leeway now, but most developers without tenure do not have that luxury.

  • Sean (unregistered) in reply to Jay

    Could be a race condition from some multithreaded stuff. Two out of three wins!

  • CType(Me, CoolKid).MakeComment (unregistered) in reply to sth.
    sth.:
    s.:
    Heh, if it's not boolean you can use my favourite bool cast operator: return !!test;
    Heh, that's amazing. Heh, you know that? Heh, you know, the person right above you didn't just post the same thing. Heh, yeah, heh, you probably, heh, didn't just look at the last post and, heh, use it to make yourself look, heh, smart. Heh.

    Oh man! BURN! Dude! What grade are you in? Can I sit with you at the cool kids table? We can slap high fives later. w00t.

  • (cs) in reply to will
    will:
    wow, im sorry, but my goodness some of you need a lesson in logic...
    Not half as much as you do. Here's lesson #1: Not all logic is Aristotelian two-valued logic.
  • (cs) in reply to Mania
    Mania:
    DaveK:
    No. No it doesn't. Not this millennium, anyway. I challenge you to find one compiler anywhere that doesn't generate identical code for the two. In fact, I challenge you to find one compiler anywhere that doesn't translate the two different ASTs into the exact same intermediate representation[*]. [*] - after folding, of course.
    Ok, first one I tried. Borland C++, latest version (I believe) poorly optimises !!.
    What's that you say, grampa? ;-) "Borland C++"? "Latest version"? I said this millennium![*]
    Mania:
    So what do I win?

    A calendar?

    Mania:
    As for the explicit cast, I agree completely. Best way to handle it. However it doesn't work in C.

    Well, "this millennium" implies C99 at least, so why not?

    [*] ps: Yes, ok, I have heard of C++ builder :)

  • step (unregistered)

    if (test == true) return true; else if (test == false) return false; else return !true && !false;

  • Matthew K (unregistered) in reply to Jay

    Just goes to show there are some really stupid programmers out there. They should be shot. or go into a career that better suites them...like...errr....errr... s**t shovelers or something.

    This guy would be off my team in 2 seconds flat with code like that.

  • Jaco (unregistered) in reply to Binks

    Or maybe the code is in a multi-threaded application and the value of test can then be changed at the last moment...

    Still doesn't make sense.

  • The origins of such badness (unregistered)

    I suspect that it is less than optimal code left after a risky refactor of some other variable to test or an even more risky search and replace, whereby moving on without review. Let's just assume the change was made and then it passed a unit test. Even extending the benefit of doubt, even if the second nested ternary operation was on another named boolean, return test && other; would have worked.

    What I don't get is this... I consider ternary operations, including nested operations, an advanced topic. Normally newbs will us an if-else structure from hell before tempting fate with the ?: operator. I wonder what lead up to this piece?

    I wonder if some refactoring utility took a pure boolean related if-then-else tree that only returned values conditionally and created this mess?

    I give up, I will go back to working on my program that attempts to understand women.

  • (cs) in reply to DaveK
    DaveK:
    will:
    wow, im sorry, but my goodness some of you need a lesson in logic...
    Not half as much as you do. Here's lesson #1: Not all logic is Aristotelian two-valued logic.
    I'd imagine that the "logic" in the code is intended to be Aristotelian two-valued logic, although I'm not even convinced that it qualifies as two-bit logic. It's far from obvious where the excluded middle might be here. (If "null," see KattMan who must be sick of repeating himself on this one. If "threading problem," see large knobkerrie from very close range.)

    Not all comments are worth getting your pantyhose in a twist.

  • Ishkandar (unregistered)

    Well, there's the known knowns, known unknowns and the unknown unknowns !! So maybe he's just being cautions !! Then again, he could be just not very good !!

  • mateus kahler (unregistered)

    This line surely is cool maybe the guy was joking

    (take it as the X file new slogan :"I Want to believe")

  • Nick (unregistered)

    Personally I would say that it was deliberate obfuscation in order to cause confusion.

    Whoever wrote that algorithm, no matter how stupid it might seem, had extremely good logic processing skills, that's a fact.

  • Nick (unregistered) in reply to Jaco
    Jaco:
    Or maybe the code is in a multi-threaded application and the value of test can then be changed at the last moment...

    Still doesn't make sense.

    WTF? That makes even less sense! No way would that slow down the CPU enough to let another operation occur. Concurrent thread handling is performed through mutex's and wait events, not boolean logic!

  • Nick (unregistered) in reply to _js_
    _js_:
    if (test == true) {
  if (test == false) { // for quantum and DNA chipsets which allow multiple simultaneous states of variables
    return false
  } else {
    return true
  }
} else {
  if (test == false) { // for quantum computers, the value might have changed due to measuring the value
    return false;
  } else {
    return true;
  }
}

    hahaha! palms face

    Quantum computing my arse.

Leave a comment on “The Test of Truth”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article