"if (! expression)" Or "if (expression == false)"??
Author
Hey, everyone. This does not really concern anything about my current project. But I was thinking about it, so I decided to start some kind of conversation. LoL. I hope it's not bother. =)
Anyhow, which statement do you recommend/prefer?
if (! expression)
{
// Code here
}
Or
if (expression == false)
{
// Code here
}
I mean, I used to use "(! expression)", but I started checking to see if the "expression" was actually "false/true/etc.". I don't really know why.
But is there really a standard for this? Or is it more of a preference depending on the person who is coding?
Because, the way I look at it, it makes it easier for me to understand exactly what I'm evaluating the expression against. And it actually makes it a little bit easier to see "== false" than "! expression". Sometimes I'll look at code, and either I'll forget the "!", or I'll read over it, and not realize that it's there.
So what does everyone else think? Which method do you use? =)
I didn't intend to "waste" anyone's time. But it just popped into my mind. And I wanted to get some answers. =)
Thanks in advance,
Matt U.
If you use "false == expression", then the compiler will catch it if (or perhaps when) you accidentally leave off one of the equal signs.
Just like he said above... if you are using ==, put false before expression, so the compiler tells you that "false" isn't a lvalue. I prefer to use !expression than (expression == false). Also, I prefer to use (expression) over (expression != 0) or (expression == true) on values or boolean stuff or anything.
I prefer if (!true) as opposed to if (true != true) or if (true == false)
less work, it looks smoother, and I like the ! operator, it kicks mucho butt :)
less work, it looks smoother, and I like the ! operator, it kicks mucho butt :)
Quote:Original post by TFS_Waldo
Hey, everyone. This does not really concern anything about my current project. But I was thinking about it, so I decided to start some kind of conversation. LoL. I hope it's not bother. =)
Anyhow, which statement do you recommend/prefer?
It depends on what expression is. In general, you should try to phrase a conditional positively -- that is, "if (expression)..." rather than "if (!expression)" -- because positives are less complicated and easier to read than negatives. For instance:
if (shouldStripWhitespace) if (!shouldStripWhitespace){ { // section A right // section B} <====== }else ======> else{ wrong { // section B // section A} }
Never explicitly use true or false in your conditionals. It's dumb and superfluous.
If you have something like this:
if (a > b == true)
what it means is this:
Evaulate a > b, which gives true.
Then compare true == true
See? Unless you seriously expect true to not equal true, don't bother with the last part.
Same goes for false. If you wanted to test if the above was false, you could do this:
if (a > b == false)
which would get evaluated like this:
evaluate a > b, which gives false
evaluate false == false, which gives true
Or maybe a < b is true?
Then we get true == false, which is false.
Again, why would you bother to test whether false equals false?
Why not just test whether the original expression failed to hold?
!(a > b) would have done the trick.
Otherwise, when do you stop?
a > b yields true
Let's compare that with true, like so:
a > b == true
that yields true *too*. So should we also compare that with true?
a > b == true == true ?
And hey, guess what, that gives us another bool, so we need to compare that with true
a > b == true == true == true
And so on. If you think that makes it "easier to read", or more intuitive, it's because you either don't understand what's going on inside the if statement, or because you haven't thought about it.
If you take it apart like I did above, it's not very intuitive at all.
The first expression returns a simple bool as well, so the simplest, easiest and clearest solution is to just use that, rather than compare it to an infinite number of bools to get the final bool, which you're for some reason more willing to use than the previous ones.
As for what LessBread said, it's true, in *some* cases it'll catch that error. But better not rely too heavily on it, because it won't always work, like in the following:
bool b = false;
if (b = expression)
The meaning is the same as in his example, but the compiler won't catch the missing =. So if you expect it to do that for you, you're in for a load of nasty bugs.
Anyway, that's what a professor at uni once spent a full hour telling us. I guess it made an impression on me...
Still, personal preferences, I guess. If you prefer statement == true == true == false, then hey, go ahead.
[Edited by - Spoonbender on April 22, 2006 8:31:49 AM]
If you have something like this:
if (a > b == true)
what it means is this:
Evaulate a > b, which gives true.
Then compare true == true
See? Unless you seriously expect true to not equal true, don't bother with the last part.
Same goes for false. If you wanted to test if the above was false, you could do this:
if (a > b == false)
which would get evaluated like this:
evaluate a > b, which gives false
evaluate false == false, which gives true
Or maybe a < b is true?
Then we get true == false, which is false.
Again, why would you bother to test whether false equals false?
Why not just test whether the original expression failed to hold?
!(a > b) would have done the trick.
Otherwise, when do you stop?
a > b yields true
Let's compare that with true, like so:
a > b == true
that yields true *too*. So should we also compare that with true?
a > b == true == true ?
And hey, guess what, that gives us another bool, so we need to compare that with true
a > b == true == true == true
And so on. If you think that makes it "easier to read", or more intuitive, it's because you either don't understand what's going on inside the if statement, or because you haven't thought about it.
If you take it apart like I did above, it's not very intuitive at all.
The first expression returns a simple bool as well, so the simplest, easiest and clearest solution is to just use that, rather than compare it to an infinite number of bools to get the final bool, which you're for some reason more willing to use than the previous ones.
As for what LessBread said, it's true, in *some* cases it'll catch that error. But better not rely too heavily on it, because it won't always work, like in the following:
bool b = false;
if (b = expression)
The meaning is the same as in his example, but the compiler won't catch the missing =. So if you expect it to do that for you, you're in for a load of nasty bugs.
Anyway, that's what a professor at uni once spent a full hour telling us. I guess it made an impression on me...
Still, personal preferences, I guess. If you prefer statement == true == true == false, then hey, go ahead.
[Edited by - Spoonbender on April 22, 2006 8:31:49 AM]
Anyone ever seen anything like this?
if (!a) //check whether a exists (?!!){}else if (a == true) //if true{}else if (a == false) //if false{}else //just in case!!{}
The only way that could possibly make any sense is if a is a class with an overloaded == and ! operators (though whoever overloaded them to work like that should be shot). Fortunately the people I work with would never do that, nor would that write that if a was a boolean, though I hear it does happen at some places.
tj963
tj963
I think boolean is better because look:
if (!someVal)
the void is my mind reads this as if not someVal and I can visual and see in one eye, very terse.
if ( someVal == false )
this just says too much. the voice in my mind reads this as if someVal is false. The time consumed in interpretting expressions takes longer.
if (!someVal)
the void is my mind reads this as if not someVal and I can visual and see in one eye, very terse.
if ( someVal == false )
this just says too much. the voice in my mind reads this as if someVal is false. The time consumed in interpretting expressions takes longer.
actually for readability, i like the: if (variable == true) expression. but like others have said that can simplified to just: if (variable) .
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
