• (cs)

    Ooh, first post I think.

    Anyway, none of these are that WTF, more of momentary lack of common sense, and nothing that usually effects a project too badly.

  • Ribbly Screwspigot (unregistered)
    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

  • Anthony (unregistered)

    great..!

  • (cs)

    very cute :)

  • Judah (unregistered) in reply to Michael Casadevall

    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 color=#0000ff size=2><FONT color=#000000> </FONT>get

    </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 color=#0000ff size=2><FONT color=#000000> </FONT>set

    </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 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>;

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

    }

    }

    }

    </FONT>
  • (cs) in reply to res2

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

    This one looks like there probably used to be some more code in there, but it got chopped out, and nobody bothered to clean up the rest of the code.

  • (cs) in reply to Ribbly Screwspigot

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

  • ChiefCrazyTalk (unregistered) in reply to stonguse

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

     

    Bingo.  That's the WTF.

  • (cs)

    if(eyes || goggles) {

        DoNothing();

    }

  • Loren Pechtel (unregistered)
    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 can think of some reasons something of this nature might be written.

    1)  It's a left-over from debugging.  Set a hardware breakpoint on a write to the address of nextIndex and the programmer put the above code in to avoid red herrings.  It would be very easy to forget to remove the conditional afterwards.

    2)  There's something about nextIndex that makes write operations to it expensive.  It's really something other than just a simple variable that it looks like.
  • Scott B. (unregistered) in reply to Michael Casadevall

    if ( (actionFlag == 0) && (actionFlag == 1) )
    {
    // Keep the world from blowing up
    }

    Well, I guess we're all doomed!

  • Krenn (unregistered)
    Alex Papadimoulis:

    if (connectionOpen || !connectionOpen)
    {
      ...
    }

    Ah, they must have been trying to write:

    if (connectionOpen != FILE_NOT_FOUND)
    {
      ...
    }
  • Ribbly Screwspigot (unregistered) in reply to ChiefCrazyTalk
    Anonymous:

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

     

    Bingo.  That's the WTF.

    Not necessarily. The context of this code block is inside a loop, where calculations are performed and different code paths can be taken.

    You might have a scenario where you only move to the next index when certain conditions are met, otherwise you continue with the loop using the index you've been using.

    Although on closer inspection it looks like the writer is trying to determine when to reset the "next" index to the "current" index. Obviously without more code, I don't know shit. But I would be open-minded to see how it would work if more code was supplied.

     

    See you in the bar,

    Ribbly

  • (cs)

    retVal = retVal || false

    <FONT color=#000000>???... </FONT><FONT color=#000000>Wow! a WTF inside a WTF. </FONT><FONT color=#000000>Truly amazing.</FONT>

    <FONT color=#000000>Watch out folks, this stuff could render a man idempotent. [H]</FONT>

  • anonymous coward (unregistered)

    here is a piece of code along those lines that i've found commented out in an app that I was maintaining:

    //if(!strFalse.isdbNull()!=false)

    //{

    //strResult=strFalse.ToString();

    //}

     

    i couldn't find the context or meaning either because none of those strings are present anywhere else in the app code.

    maybe it was some previous maintenance's cruel joke or something

  • Xpovos (unregistered)

    //remove this reply

  • gwfc (unregistered)

    Gene Wirchenko, where are you?
    I miss you.

    Sincerely,

    gwfc

  • (cs)
    Alex Papadimoulis:

    if (connectionOpen || !connectionOpen)
    {
      ...
    }


    if (toB || !toB)
    {
        return that_is_the_question();
    }
  • (cs) in reply to anonymous coward

    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.

  • (cs)

    Reminds me of something I wrote once:

    std::string role;  // assume this is assigned somewhere else

    ...
    if ( role != "something" || role != "something else" )
    {
        return;
    }
    // wtf isn't anything here being executed??
    ...

    --
    Bill C++

  • ChiefCrazyTalk (unregistered) in reply to Manni
    Manni:

    if(eyes || goggles) {

        DoNothing();

    }

     

    I believe this is more correct

     

    if(eyes && goggles) {

        DoNothing();

    }

  • (cs) in reply to Ribbly Screwspigot
    Anonymous:
    Anonymous:

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

     

    Bingo.  That's the WTF.

    Not necessarily. The context of this code block is inside a loop, where calculations are performed and different code paths can be taken.

    See you in the bar,

    Ribbly

     

    Uhhh The SAME code path will be taken immediately following this statement, whether you are in a loop, outside of a loop, or in a bar.

    The only real reason to do this code is if your = operator is overloaded and does some weird stuff, or it is very expensive to do a write. Save the few cycles to do the comparison and just set the value.

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

    if(eyes || goggles) {

        DoNothing();

    }

    I believe this is more correct

    if(eyes && goggles) {

        DoNothing();

    }

    Perl is your language of choice here:

    <FONT face="Courier New">my $eyes;</FONT>

    <FONT face="Courier New">$the_goggles->do_nothing();</FONT>

  • (cs) in reply to Krenn
    Alex Papadimoulis:

    if (connectionOpen || !connectionOpen)
    {
      ...
    }

     

    As we learned yesterday a bool has a third state, not true or false, so this is a perfectly legitimate statement.  Therefore I'm certain the code edited out handles the situation when the process is unsure if the connection is open.

  • (cs)
    Alex Papadimoulis:

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

    Ooooo. A brillant way to execute code the instant the actionFlag changes from 0 to 1! Who needs events or callbacks?

    --Rank

  • (cs) in reply to ChiefCrazyTalk
    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;
    }
  • Pyromancer (unregistered) in reply to R.Flowers

    What? no isTrue functions today?[:'(]

  • (cs) in reply to Rank Amateur

    Monday:

    <FONT face="Courier New"><FONT color=#006400>//Remove the following line:</FONT>
    currentUserId = currentUserId</FONT>;

    Tuesday:

    <FONT face="Courier New" color=#006400>//Remove the following line:</FONT>

    Wednesday:

    <FONT face="Courier New" color=#006400>//Remove the following comment:
    //Remove the following line:</FONT>

    Thursday:

    <FONT face="Courier New" color=#006400>//Remove the following comment:</FONT>

    Friday:

    <FONT face="Courier New" color=#006400>//Remove this and the following comment:
    //Remove the following comment:</FONT>

    Friday night:

    <FONT face="Courier New" color=#006400>//Remove and the following comment:
    </FONT>

    --Rank

     

     

  • Morbii (unregistered) in reply to Pyromancer

    Many of these can be explained by poorly executed operator overloads :P

  • (cs)

    Alex Papadimoulis:

        retVal = retVal || false;


    I never get sick of this kind of stupid.

  • Pyromancer (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;
    }

    hey, but eyes must include left and right eye, they are different you know

    if(Goggles!=null){

       Goggles.Lens[Left].Shatter();  

        if(MyEyes[Left]!=null)

       MyEyes[Left].State=EyeState.Burning;

    Goggles.Lens[Right].Shatter();   

      if(MyEyes[Right]!=null)

       MyEyes[Right].State=EyeState.Burning;

    }else{

    delete(MyEyes);

    }

    of course this doesn't cover cases of glass eyes ,contact lenses, and direct brain damage in case of no eyes and no goggles

  • Donny (unregistered) in reply to chrismcb
    chrismcb:
    Anonymous:
    Anonymous:

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

     

    Bingo.  That's the WTF.

    Not necessarily. The context of this code block is inside a loop, where calculations are performed and different code paths can be taken.

    See you in the bar,

    Ribbly

     

    Uhhh The SAME code path will be taken immediately following this statement, whether you are in a loop, outside of a loop, or in a bar.

    The only real reason to do this code is if your = operator is overloaded and does some weird stuff, or it is very expensive to do a write. Save the few cycles to do the comparison and just set the value.



    What if you wanted to do something only if the value was different?

    static unsigned int nOldState = 0;

    if(nOldState != GetState())
    {
        nOldState = GetState();
        Update();
    }
    OtherFunction();

    In this case you wouldn't want Update() to be called unless the state was different.
  • (cs) in reply to zip

    Now I'm not sure if this really falls under "bools" or "ifs" ... but no less, here is a rather strange "error handling" block that James D. discovered ...

    if (errorval == NO_ERROR)
    {
      nextProcessCode = "continue";
    }
    else
    {
      // show the error
      currentUserId = currentUserId; //remove this line
    }
    Not a WTF, considering it was tagged for removal.  I use this kind of thing all the time in "//do nothing" blocks so I have something to nail a breakpoint to.  I would guess the placement was just temp code that never got finished.
    Sincerely,
    Gene Wirchenko sucks 
    (dear lord of HTML please don't let the forum software butcher this post)
  • Randolpho (unregistered)
    Alex Papadimoulis:

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

    return retVal; }

    The real WTF is that these aren't bitwise operators.

  • C# wannabe (unregistered)
    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?

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

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

     

    Bingo.  That's the WTF.

    Not necessarily. The context of this code block is inside a loop, where calculations are performed and different code paths can be taken.

    See you in the bar,

    Ribbly

     

    Uhhh The SAME code path will be taken immediately following this statement, whether you are in a loop, outside of a loop, or in a bar.

    The only real reason to do this code is if your = operator is overloaded and does some weird stuff, or it is very expensive to do a write. Save the few cycles to do the comparison and just set the value.

    There could also be some object stuff going on there, there are some languages (.NET for example) where there can be very little difference between an object and a variable (let me correct myself, there is no difference in .NET, everything is an object untill you get down to the very core of the language... which I never plan on doing) This code can easily compare two objects and if they are not the same then copy one object to the other, in that copy function there could be a ton of stuff going on whereas very little would go on in the compare... either way it would be nice to more about what's going on around this bit of code.

    However it's more likely that they are just doing this for complexity/confusion sake.

    Erik of Ekedahl

  • Monkey (unregistered) in reply to Judah
    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.
  • :w (unregistered) in reply to Rank Amateur

    if(language == english)
    {
        st = "whose";
    }
    else
    {
        //st = "who's";
        st = "whose";
    }

    </irony>

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


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


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


    Probably a breakpoint line for the debugger.


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


    If this is C++ and actionFlag is of some obscure class (which overwrites == in a strange way), it might actually evaluate to true.

  • (cs) in reply to Doobie Dan

    <font size="1">

    Doobie Dan:
    </font>
    <font size="1">(dear lord of HTML please don't let the forum software butcher this post)</font>
    <font size="1">


    <font size="2">Sorry, you didn't pray hard enough.  You have been pwned.

    Sincerely,

    The Lord
    </font>
    </font>

  • (cs) in reply to C# wannabe

    Yes, C# has properties, but the naming convention when writing them is to capitalize the first letter as well.  They may still be properties, but they don't LOOK like it.

  • (cs)
    Alex Papadimoulis:

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



    This is obvious-  he's an electrical engineer who wants to make this logic edge triggered.  Its a huge advance in CS.

    (TO those with no electircal background-  to do clock based circuits, you actually do things like (clock NOR (NOT clock)) to detect when a wire signal changes-  since the extra NOT gate will take a non-zero time to complete, that result will actually be 1 for a fraction of a nanosecond when clock goes from 1 to 0).
  • (cs) in reply to wk2x

    wk2x:
    Reminds me of something I wrote once:

    std::string role;  // assume this is assigned somewhere else

    ...
    if ( role != "something" || role != "something else" )
    {
        return;
    }
    // wtf isn't anything here being executed??
    ...

    --
    Bill C++

    I've made that mistake lots and felt really dumb each time. Now I just test the stuff before checking in so I minimize the risk of someone else noticing the error before I fix it. Though hardest part about that bug for me is trying to convince someone else that they should be using && instead of ||. Showing someone DeMorgan's laws doesn't usually help the situation. Maybe I should ask people to debug that thing as part of an interview...

  • (cs) in reply to ChiefCrazyTalk

     

    Anonymous:
    Manni:

    if(eyes || goggles) {

        DoNothing();

    }

     

    I believe this is more correct

     

    if(eyes && goggles) {

        DoNothing();

    }


    for each eye { goggle = .null. }
  • Jack Crow (unregistered) in reply to R.Flowers

    I just laughed harder at that Simpson's quote than I did at any of the code examples.

  • (cs) in reply to stonguse
    stonguse:
    Why not just skip the check and set
    nextIndex = currIndex?
    Isn't that the final result regardless?



    I imagine at one point there was more code there, and that step was to make sure it was iterating correctly though a big pile of values.

    Every now and again I end up setting up an "if(managementHasMadeUpItsMind){}" block to cut out a big chunk of control logic that someone has decided they don't need, but which I privately believe they'll be asking me to implement again in a month or two, which leaves "wtf?" moments lying around in my code, but saves me a lot of implementation time in the future. Just set managementHasMadeUpItsMind = True; and you're good to go surf the web for 5 days while you're "implementing" logic that you knew they didn't want removed in the first place.
  • xcor057 (unregistered)
    if (errorval == NO_ERROR)
    {
      nextProcessCode = "continue";
    }
    else
    {
      // show the error
      currentUserId = currentUserId; //remove this line
    }
    I guess users REALLY ARE the root of all errors.
  • Freddy fred fred (unregistered)

    This reminds me of a couple of almost-wtf's I found in a script a little while ago. It's easy to understand how these things happen as code is revised, but basically it looked like this:

    if ((a and b) or (b)) { do_stuff(); }

    where a and b were actually pretty long conditions. Then later there was this:

    if (a and !b) { // lots of stuff if (b) { // lots more stuff } }

    A different a and b, but still lengthy statements (and b was not recalculated in any way).

  • (cs) in reply to Rank Amateur
    Rank Amateur:

    Monday:

    <FONT face="Courier New"><FONT color=#006400>//Remove the following line:</FONT>
    currentUserId = currentUserId</FONT>;

    Tuesday:

    <FONT face="Courier New" color=#006400>//Remove the following line:</FONT>

    Wednesday:

    <FONT face="Courier New" color=#006400>//Remove the following comment:
    //Remove the following line:</FONT>

    Thursday:

    <FONT face="Courier New" color=#006400>//Remove the following comment:</FONT>

    Friday:

    <FONT face="Courier New" color=#006400>//Remove this and the following comment:
    //Remove the following comment:</FONT>

    Friday night:

    <FONT face="Courier New" color=#006400>//Remove and the following comment:
    </FONT>

    --Rank

    Bwahaha.

    Reminds me of my trash company. Do you know how HARD it is to throw away a trash can??

    Last week after they emptied our trash, one of the cans got blown out into the road (big squarish green plastic can with wheels). A car hit it and destroyed it. I mean, destroyed--wheels gone, bottom end flattened like a pancake. The top is still squarish, so it might hold a small bit of trash if I propped it up against the house or something, but anyone who sees it is going to say "jeez, what happened to your trash can?".

    So this week, I put the good can out at the curb, and next to it we were throwing away a big empty box. So I put a bag or two of trash in the box, then I cram the mangled trash can upside-down inside the box. The message is obvious, right? "This is trash. Please haul it away."

    Nope. They pulled the mangled trash can out of the top of the empty box, and left it on the curb.

    I know if I leave a sign that says "please take this", they'll just take the note :)

  • (cs) in reply to ChiefCrazyTalk
    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...

Leave a comment on “Of Ifs And Bools”

Log In or post as a guest

Replying to comment #:

« Return to Article