• Kiss me, I'm Polish (unregistered) in reply to WWWWolf
    WWWWolf:
    Anonymous:

    I believe this is more correct

    if(eyes && goggles) {

        DoNothing();

    }



    Funny, I always thought "eyes + goggles == eyes" was more closer to the original quote...


    I don't get this. It's been fartillion posts about goggles doing nothing. Where is the joke hidden?

    Hypocritically,
    Some Random Guy
  • Wayne (unregistered)
    Alex Papadimoulis:
    if ( BitCount != 8 )                                        
      expectedBits = 8;
    else
      expectedBits = BitCount;

    This is a particularly elegant way of setting expectedBits to 8.

  • (cs)
    Alex Papadimoulis:
    bool validateCheckAmount(float checkAmt)
    {
      bool retVal = false;
      if (checkAmt == 0) 
      {
        retVal = retVal || false;
      }
      else
      {
        retVal = retVal || true;
      }
    

    return retVal; }

    Is no one going to complain that negative check amounts are to be considered Valid?

  • ASSHOLE (unregistered) in reply to Kiss me, I'm Polish
    Anonymous:
    I don't get this. It's been fartillion posts about goggles doing nothing. Where is the joke hidden?

    Hypocritically,
    Some Random Guy

    It's a reference to a crappy children's cartoon called Futurama.
  • (cs) in reply to Kiss me, I'm Polish
    Anonymous:
    WWWWolf:
    Anonymous:

    I believe this is more correct

    if(eyes && goggles) {

        DoNothing();

    }



    Funny, I always thought "eyes + goggles == eyes" was more closer to the original quote...


    I don't get this. It's been fartillion posts about goggles doing nothing. Where is the joke hidden?

    Hypocritically,
    Some Random Guy

    UP goggles

    Wikipedia article on Rainier Wolfcastle, the original author of the quote (see the end of the article)

  • (cs) in reply to ASSHOLE
    Anonymous:
    Anonymous:
    I don't get this. It's been fartillion posts about goggles doing nothing. Where is the joke hidden?

    Hypocritically,
    Some Random Guy

    It's a reference to a crappy children's cartoon called Futurama.

    wrong! Its the simpsons. But I guess we already know that, the last guy beat me to it. Curse this bloody forum software!

  • (cs) in reply to OneFactor

    Hey, now ... using that piece of code in an interview is a great idea.  I might just do that if I ever interview anyone again.

    I think this wtf of mine was the result of some refactoring I had to do a while ago, so at least it didn't show up right away - I think I was actually adding the "something else" role (names changed to protect proprietary information, of course), and this one just slipped by me.

    The sad part is that it sat there and escaped my attention for literally months, all the while I was wondering why the data that was supposed be sent out in the rest of the function wasn't going out.  And you're right, whoever said the thing about the overloaded operators ... if these had been ints instead of std::strings, the compiler probably would have warned me at least.

    Oh well ... If we can't wtf ourselves, who can we wtf?

    By the way, hi everyone - I'm new. ;)  Is there an official introductions thread somewhere?  I and my very talented co-workers spent most of the day yesterday ROFL-ing over this site - very nice!

    --
    Bill C

  • Norman H (unregistered)

    That is TOO good, I laughed till it hurt!

    This is great!

  • Norman H (unregistered) in reply to Monkey

    Without any coupling we have NOTHING, everything has coupling at some level, there are some forms of coupling that are detrimental to the future maintenance of a system.

    You might try raising an event to let the client know that things are changing since you are modifying state with a property.

  • anonymous (unregistered) in reply to ammoQ

    even without operator overloading, reading a variable may well be cheaper than writing.  Think MP systems, and what it takes to acquire a cache line for write (e.g., potentially invalidating other CPUs' copies) vs. acquiring it for read (in which case multiple processors may share the line).

    I've seen the "if (foo != bar) { foo = bar; }" idiom used more than once, intentionally, for this purpose.

  • (cs) in reply to ASSHOLE
    Anonymous:
    Anonymous:
    I don't get this. It's been fartillion posts about goggles doing nothing. Where is the joke hidden?

    Hypocritically,
    Some Random Guy

    It's a reference to a crappy children's cartoon called Futurama.


    Futurama is neither crappy nor a children's cartoon. It's brilliant comedic gold.
  • Merlin (unregistered)
    if (checkAmt == 0) 

    This one is all the more amazing that comparing a floating point number to exactly zero is usually a very bad idea.
    Strict equality and FP numbers don't mix. Usually.

    The rest is just icing on the cake...
  • ChiefCrazyTalk (unregistered) in reply to Djinn
    Djinn:
    Anonymous:
    Anonymous:
    I don't get this. It's been fartillion posts about goggles doing nothing. Where is the joke hidden?

    Hypocritically,
    Some Random Guy

    It's a reference to a crappy children's cartoon called Futurama.


    Futurama is neither crappy nor a children's cartoon. It's brilliant comedic gold.

    thanks for affording me the opportunity to mentione my favorite Futurama quote (as others have mentioned, the goggles bit is from The Simpsons, also not crappy and not for children.)

    "Dear Lord, that's over 150 atmospheres of pressure!"

    "How may atmospheres can the ship withstand, professor?"

    "Well, it's a space ship. So anywhere between 0 and 1"

  • thweetie (unregistered) in reply to ChiefCrazyTalk

    Ah, Matt Groening, comic genius.

  • anonymous coward (unregistered) in reply to Ytram
    Ytram:
    Anonymous:
    Manni:

    if(eyes || goggles) {

        DoNothing();

    }

     

    I believe this is more correct

     

    if(eyes && goggles) {

        DoNothing();

    }



    You're both wrong:

    if(goggles && DoNothing())
    {
        MyEyes.EyeState = EyeState.Burning;
    }


    How about:
    public static virtual const void Goggles() const
    {
        return false;
        // TODO: implement this
    }

    /* later... */

    if (Goggles())
        return;
    this.eyes.ApplyAcid();

  • Paul Hoadley (unregistered) in reply to Michael Casadevall
    Sonic McTails:
    Anyway, none of these are that WTF, more of momentary lack of common sense, and nothing that usually effects a project too badly.

    Momentary lack of common sense? Some of those are profoundly moronic, and well deserving of a WTF.

  • Paul Hoadley (unregistered) in reply to Paul Hoadley

    Err... OK. What's the secret with the forum software then?

  • crazyfrog (unregistered)

    Isn't the first one an implementation of my "favourite" coding pattern:
    "Use only one return statement within a funtion body." ;-)

  • (cs) in reply to Paul Hoadley
    Anonymous:
    Err... OK. What's the secret with the forum software then?

    It's a highly magical entity with the goals of taking over the earth and provoking mass suicides of users via the careful but random mangling of their posts.

  • .* (unregistered) in reply to Paul Hoadley

    Always click the "HTML" tag on the editor

  • A non e mouse (unregistered)

    As an interesting side note: x == x will NOT always evaluate to true in nqc if you pass a sensor as a const reference, since the sensor gets polled every time the variable in the inlined function gets accessed. So something that would look like a WTF, isn't.

  • deuterium (unregistered) in reply to chrismcb

    An example of where write operations might be expensive and where there might be different code paths independent of this loop is if there is some type of logging or journaling of the variable changes going on.  If, for example, this snippit of code were part of some type of population genetics model or weather model, that index could refer to an interation of code that gets logged and cross referenced with a time stamp and/or some other information.  Put another way, there are time dependent population modeling problems where it's useful (if not required) to have a record of not just if, but also when variables change.  currIndex could be defined at the beginning of the program to always write to a logfile on disk (e.g. making it very expensive).  At some later date in time, that logfile might be the basis for a new run of the model inside the searchspace of the problem domain (and a different code path taken). 

    Of course, population models and weather simulations might have been the last thing on this guy's mind when coding that snippet up.  But you never know. 

  • hm (unregistered) in reply to .*
    Anonymous:
    Always click the "HTML" tag on the editor


    I have more success with the opposite... 
  • geek (unregistered) in reply to ammoQ
    ammoQ:


    This comes from the human thinking "doing something" (like an assignment) is more expensive than "looking at something".


    Especially if the "something" in question is a stripper

  • None Of The Above (unregistered) in reply to chaim79
    chaim79:

    there are some languages (.NET for example) where there can be very little difference between an object and a variable



    .
    .NET is a particularly poor example of this.

    Mostly because .NET is not a language.

  • Rehan (unregistered) in reply to stonguse

    Hmm...maybe nextIndex and currIndex are objects that are cheap to test for non-equality but expensive to assign???

  • Myrd (unregistered) in reply to A non e mouse
    As an interesting side note: x == x will NOT always evaluate to true in nqc if you pass a sensor as a const reference, since the sensor gets polled every time the variable in the inlined function gets accessed.

    Actually, that's just a WTF of the language. Stuff like that (ie sensor polls) should be returned by a function call, not by a variable. With function return values, x() == x() is obviously not always true (consider rand() == rand()). So obviously, whoever designed nqc should have made it a function, but instead made it a WTF! (And yes, I know someone is dying to bring up the infamous 'volatile' keyword. Grrr.)

  • (cs)
    Alex Papadimoulis:

    if ( (actionFlag == 0) && (actionFlag == 1) )
    {
      // ...
    }



    That's awsome... it will probably work in 20 years. By then though programming would probably look like this:

    f = 5m+4z-2x^2+6u^5
    g = f '
    d = g / 6m

    Don't even ask what that is... just made up algebraic crap with a derivitive thrown in for fun. Maybe it would calculate the video or something...
  • (cs) in reply to C# wannabe
    Anonymous:
    Alex Papadimoulis:

    Deb Edb noticed that some of the coders at an ISO-9001-certified company he worked at had a certain sweet spot for Schrödinger's ...

    if ( (actionFlag == 0) && (actionFlag == 1) )
    {
      // ...
    }

    Disclaimer: I have never programmed C#

    Doesn't C# have "properties". If so, it is possible that actionFlag actually triggers a "hidden" property method that could be doing lots of stuff, including changing the value the next time it is accessed?



    if that is the case, not only should the Dev be taken out and shot for something so obscure as that, but also MS, for giving the Dev that weapon of mass distraction in the first place...
  • Anonymous Monk (unregistered) in reply to sao

    All of this reminds me of the system that we recently re-built from scratch. It was littered with things like

    if ($result->codeEquals(200)) {
        # do stuff
    }
    elsif( $result->{'code'} == 300 ) {
    }
    

    And the

    codeEquals()
    method was this:

    sub codeEquals {
        my ($result, $code) = @_;
        if ($result->{'code'} == $code) {
            return 1;
        }
        else {
            return 0;
        }
    }
    

    Damn, I hated that system....

  • LarsW (unregistered) in reply to OneFactor
    OneFactor:

    Is it just me or is anyone else thinking that those things that look like variables could be properties with side effects, that the app could fail if we nuke the apparently redundant stuff, and so a developer might just leave that stuff there on the if it ain't broke don't fix it principle.

    with the introduction of properties, you can never understand a snippet of code any more because it just might be hiding other complexities. You can no longer look at a snippet and confidently say you know for sure it does not call something and thus understand it.



    I reacted to this too when I heard about it in C#. I guess IDEs can help you with it, but still. I think I'll stay with Java. I like strict exception handling too. Not everyones cup of tea, I know.
  • (cs) in reply to Judah

    I agree, this is not a WTF.
    Checking a variable before setting a property (C#, Delphi) is sometimes a must, especially when OOP "enthusiasts" pack their property setter methods with computation-extensive logic.

  • jon without an h (unregistered) in reply to C# wannabe

    Yes, it's possible.  And if it were true, that would be a HUGE WTF.  I can't think of a single situation where a [decent] C# programmer would want to write a property that would change its own return value just by being accessed.

  • Chris Brooksbank (unregistered) in reply to eddieboston
    if( nextIndex != currIndex )
    {
    nextIndex = currIndex;
    }

    What if setting nextIndex sets off some resource consuming code as a sideeffect.
    e.g. an event gets fired or a property setter piece of code fires.
    Maybe that was in the coders mind when they wrote it.
  • jon without an h (unregistered) in reply to C# wannabe

    *sigh*

    Anonymous:
    Alex Papadimoulis:

    Deb Edb noticed that some of the coders at an ISO-9001-certified company he worked at had a certain sweet spot for Schrödinger's ...

    if ( (actionFlag == 0) && (actionFlag == 1) )
    {
      // ...
    }

    Disclaimer: I have never programmed C#

    Doesn't C# have "properties". If so, it is possible that actionFlag actually triggers a "hidden" property method that could be doing lots of stuff, including changing the value the next time it is accessed?

    Yes, it's possible.  And if it were true, that would be a HUGE WTF.  I can't think of a single situation where a (decent) C# programmer would want to write a property that would change its own return value just by being accessed.

  • Ian (unregistered) in reply to jon without an h
    Anonymous:
    Yes, it's possible.  And if it were true, that would be a HUGE WTF.  I can't think of a single situation where a [decent] C# programmer would want to write a property that would change its own return value just by being accessed.


    Here's one....
    Suppose you were implementing a Lazy load pattern, so that the object is not actually populated until a property is accessed....

    In any case it wouldn't explain this


    if( nextIndex != currIndex ) { nextIndex = currIndex; }
    Most likely there used to be some more code there that got deleted and not cleaned up.
  • Ian (unregistered) in reply to Ian
    bool validateCheckAmount(float checkAmt)
    {
    bool retVal = false;
    if (checkAmt == 0)
    {
    retVal = retVal || false;
    }
    else
    {
    retVal = retVal || true;
    }

    return retVal;
    }


    At the risk of defending this, there was probably more code originally, so that retVal might have already been set when it got to the if statement.

  • (cs) in reply to Monkey
    Anonymous:
    Anonymous:

    if( nextIndex != currIndex )
    {
    nextIndex = currIndex;
    }
    What? I use that many times, especially when you're doing lots of logic depending on the value. Take the following C# get/set property for example:
    <font size="2"></font>

    <font color="#0000ff" size="2">public</font><font size="2"> </font><font color="#0000ff" size="2">bool</font><font size="2"> IsEnabled</font>

    <font size="2">{</font>

    <font color="#0000ff" size="2"><font color="#000000"> </font>get</font>

    <font size="2"></font>

    <font size="2"> {</font>

    <font color="#0000ff" size="2"><font color="#000000"> </font>return</font><font size="2"> </font><font color="#0000ff" size="2">this</font><font size="2">.enabled;</font>

    <font size="2"> }</font>

    <font color="#0000ff" size="2"><font color="#000000"> </font>set</font>

    <font size="2"></font>

    <font size="2"> {</font>

    <font color="#0000ff" size="2"><font color="#000000"> </font>if</font><font size="2"> (</font><font color="#0000ff" size="2">this</font><font size="2">.enabled != </font><font color="#0000ff" size="2">value</font><font size="2">)</font>

    <font size="2"> {</font>

    <font color="#0000ff" size="2"><font color="#000000"> </font>this</font><font size="2">.enabled = </font><font color="#0000ff" size="2">value</font><font size="2">;</font>

    <font size="2"> UpdateAllSortsOfStuff(); <font color="#006400">// We don't want to do this unless enabled has been changed.</font></font>

    <font size="2"> }</font>

    <font size="2"> }</font>

    <font size="2">}</font>



    That's called coupling. Maybe you should post it here.


    How about you're in a nice observer pattern where changing a value will notify all observing objects of the change?  that could really cascade into a big cpu-suckup everytime a user presses 'save' without changing anything to this variable.  Is using a GoF pattern also coupling?  At some point it might be interesting to know whether a variable has changed (think changelogging, think observing stuff, think whatever you can imagine), and isn't the setter of that variable the best possible position to do so?  Or do you want code concerning the change of a single variable scattered around all your project?  Doesn't seem very maintainable to me.

  • Remco Gerlich (unregistered) in reply to Wayne
    Anonymous:
    Alex Papadimoulis:
    if ( BitCount != 8 )                                        
    expectedBits = 8;
    else expectedBits = BitCount;

    This is a particularly elegant way of setting expectedBits to 8.


    Indeed. The elegance is that they used the pleasingly simple "BitCount", where they could have used a random much more complicated expression. As long as the result can be legally compared to an int in whatever language this is, you can replace it with anything without side effects, and it won't make a difference.

  • Oliver (unregistered)

    <FONT face=Verdana color=#000000 size=2>solved the connectionOpen || !connectionOpen mistery [H]

    public bool connectionOpen
    {
       get{return _connectionOpen = !_connectionOpen;}
    }</FONT> 

  • yay4furryanimals (unregistered)
    Alex Papadimoulis:

    if (errorval == NO_ERROR)
    {
      nextProcessCode = "continue";
    }
    else
    {
      // show the error
      currentUserId = currentUserId; //remove this line
    }



    I didn't have time to read other responses but, some of these could be used for debugging purposes where the debugger's performance to check conditional breakpoints is so slow that it's much faster to write a conditional statement and do self assignment to break at a particular point upon certain conditions.

    Regardless, the comments are yeah, very misleading if that was the original intent.
  • Syarzhuk (unregistered)

    float checkAmt is obviously the biggest WTF of them all.

  • (cs) in reply to Ytram
    Ytram:
    Anonymous:
    Manni:

    if(eyes || goggles) {

        DoNothing();

    }

     

    I believe this is more correct

     

    if(eyes && goggles) {

        DoNothing();

    }



    You're both wrong:

    if(goggles && DoNothing())
    {
        MyEyes.EyeState = EyeState.Burning;
    }


    We really just need to make a function for that joke so it doesn't get reinvented in each thread.
  • (cs)
    Alex Papadimoulis:

    bool validateCheckAmount(float checkAmt)
    {
      bool retVal = false;
      if (checkAmt == 0) 
      {
        retVal = retVal || false;
      }
      else
      {
        retVal = retVal || true;
      }
    

    return retVal; }

    Nothing really wrong with that.  What if the logic for validating a check amount changes in the future?  They'll be glad they separated the validation logic when they're making a change to one function instead of a whole ton of statements that could be tough to track down.

  • kosiarz (unregistered) in reply to Ribbly Screwspigot
    Anonymous:
    Alex Papadimoulis:

    There is some hope though; Brian Boccia's coworker was able to speed up variable assignment without requiring an else block ...

    if( nextIndex != currIndex )
    {
        nextIndex = currIndex;
    }

    I have used logic like this from time to time. It's useful when you are doing crazy matrix stuff, or drawing operations. Reminds me of ActionScript.

     

    See you in the bar,

    Ribbly



    sadly there is no logic in this code, because it is equal to
    nextIndex = currIndex;
  • (cs) in reply to OneFactor
    OneFactor:

    with the introduction of properties, you can never understand a snippet of code any more because it just might be hiding other complexities. You can no longer look at a snippet and confidently say you know for sure it does not call something and thus understand it.

    Well, with the introduction of operator overloading some decades ago, really.

  • (cs) in reply to WWWWolf
    WWWWolf:
    Anonymous:

    I believe this is more correct

    if(eyes && goggles) {

        DoNothing();

    }



    Funny, I always thought "eyes + goggles == eyes" was more closer to the original quote...

    I'm surprised no one came up with this to match the WTF:

    if (goggles || !goggles) burn_eyes();

  • (cs)
    Alex Papadimoulis:
    if (connectionOpen || !connectionOpen)
    {
    ...
    }


    I've actually seen this a lot with database connections.  In addition Open and Closed there is also Connecting, Broken, and a couple of others.  Not opened, not closed.

    Still not exactly a great way to handle it though.
  • jicket (unregistered)

    "Then there's William, who's coworker always insisted..."

    It's always fun reading a post that makes fun of someone else's syntax and logic, yet can't be bothered to write syntactically correct sentences.

  • bleh (unregistered) in reply to ChiefCrazyTalk

    Assignment is expensive, there is no point doing an assignment statement unless you need to.

    Anonymous:

    stonguse:
    Why not just skip the check and set
    nextIndex = currIndex?
    Isn't that the final result regardless?

     

    Bingo.  That's the WTF.

Leave a comment on “Of Ifs And Bools”

Log In or post as a guest

Replying to comment #62120:

« Return to Article