Comment On Of Ifs And Bools

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.

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

great..!

very cute :)

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:

public bool IsEnabled
{
    get
    {
        return this.enabled;
    }
    set
    {
        if (this.enabled != value)
        {
            this.enabled = value;
            UpdateAllSortsOfStuff(); // We don't want to do this unless enabled has been changed.
        }
    }
}

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.

Why not just skip the check and set

nextIndex = currIndex?

Isn't that the final result regardless?

stonguse:

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

 

Bingo.  That's the WTF.

if(eyes || goggles) {

    DoNothing();

}

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.

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

Well, I guess we're all doomed!

Alex Papadimoulis:

if (connectionOpen || !connectionOpen)

{

  ...

}

Ah, they must have been trying to write:

if (connectionOpen != FILE_NOT_FOUND)

{

  ...

}

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

retVal = retVal || false

???... Wow! a WTF inside a WTF. Truly amazing.

Watch out folks, this stuff could render a man idempotent. [H]

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

//remove this reply

Gene Wirchenko, where are you?
I miss you.

Sincerely,

gwfc

Alex Papadimoulis:

if (connectionOpen || !connectionOpen)

{

  ...

}

if (toB || !toB)
{
    return that_is_the_question();
}

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.

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++

Manni:

if(eyes || goggles) {

    DoNothing();

}

 

I believe this is more correct

 

if(eyes && goggles) {

    DoNothing();

}

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.

Anonymous:

Manni:

if(eyes || goggles) {

    DoNothing();

}

I believe this is more correct

if(eyes && goggles) {

    DoNothing();

}

Perl is your language of choice here:

my $eyes;

$the_goggles->do_nothing();

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.

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

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

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

Monday:

//Remove the following line:
currentUserId = currentUserId;

Tuesday:

//Remove the following line:

Wednesday:

//Remove the following comment:
//Remove the following line:

Thursday:

//Remove the following comment:

Friday:

//Remove this and the following comment:
//Remove the following comment:

Friday night:

//Remove and the following comment:

--Rank

 

 

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

Alex Papadimoulis:

    retVal = retVal || false;

I never get sick of this kind of stupid.

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

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.

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)

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.

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?

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

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:

public bool IsEnabled
{
    get
    {
        return this.enabled;
    }
    set
    {
        if (this.enabled != value)
        {
            this.enabled = value;
            UpdateAllSortsOfStuff(); // We don't want to do this unless enabled has been changed.
        }
    }
}

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

if(language == english)

{

    st = "whose";

}

else

{

    //st = "who\'s";

    st = "whose";

}

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.

Doobie Dan:

(dear lord of HTML please don't let the forum software butcher this post)

Sorry, you didn't pray hard enough.  You have been pwned.



Sincerely,



The Lord

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.

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).

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...

 

Anonymous:

Manni:

if(eyes || goggles) {

    DoNothing();

}

 

I believe this is more correct

 

if(eyes && goggles) {

    DoNothing();

}

for each eye { goggle = .null. }

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

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.

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.

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).

Rank Amateur:

Monday:

//Remove the following line:
currentUserId = currentUserId;

Tuesday:

//Remove the following line:

Wednesday:

//Remove the following comment:
//Remove the following line:

Thursday:

//Remove the following comment:

Friday:

//Remove this and the following comment:
//Remove the following comment:

Friday night:

//Remove and the following comment:

--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 :)

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...