There is a colleague of mine who constantly writes:
if (someBool == true)
It drives me up the wall! Should I make a big deal of it or just drop it?
It's a code smell for a novice developer. They have yet to master/internalize the boolean condition and must explicitly evaluate to the true or false condition.
In JavaScript, I prefer if(bool)
when I have sufficient documentation explaining what the method expects... but when evaluation of true can mean the variable exists, equals the number 1 or the boolean true, it's tougher.
Strongly typing in JS also means less flexibility. Tough call. Strongly typed languages, lay down the hammer. Otherwise, ask why he does it?
Actually, there's your answer: ask him why. Then correct him.
use it as an opportunity to teach him. he will respect you more if you do. wouldn't you want someone to do the same for you?
Research shows that code with many redundancies correlates strongly with errors. Here's an interesting paper on the matter (PDF alert).
Yes, This is a kind of programmers mind set. All the time they considers "if condition" has no existence with out an expression with symbols =,<,>... I've seen situations people really get struggle as like "function return"
if(RowsAffected > 0) { return true; } else { return false; }
Programmers need to watch their code from the real time angle.. :)
Yes, it's a big deal because the name of the boolean should tell that it is boolean. Says if you have this piece of code:
bool arrayIsEmpty = array.length == 0;
if (arrayIsEmpty) { ... }
It is already easy to read so you won't need == true
, even for the person or programmer with less sense of evaluation.
Programming conventions are not necessarily "right" or "wrong". They exist to give the program a familiar structure to those reading it, so that possible mistakes will stand out more clearly -- it is difficult to "see" a problem if everything is slightly wrong-looking to you.
The important thing is that conventions be clearly defined and agreed upon by all participants (even if the agreement is like "I agree to use this convention while I work here" :), otherwise it does more harm than good.
Of course, the particularly case of comparing a boolean to true is plain wrong and to be avoided at all costs. ;-)
I write if(var==false) because after writing var i dont feel like backtracking and write ! behind it. Also i like how ==false makes it look more clear.
However == true is just weird. I dont know if there is a point of making a big deal. I wouldnt unless he is pushing others to use it or to make it a coding standard.
You can try approaching your colleague with the following example:
if ((x == 3) == true) {
...
}
He should say that the == true
is redundant and should be rewritten as
if (x == 3) {
...
}
since x == 3
is already a boolean expression.
Now present him the someBool == true
example, but slightly rewritten:
if ((someBool) == true) {
...
}
Since someBool
is already a boolean, by comparison with the previous example, it should now be clear that the == true
is redundant in this example, too. Thus, it should be rewritten as:
if (someBool) {
...
}
This may get some of your nickers in a wad.
We have extension methods for .IsTrue and .IsFalse for the bool type.
So we write
if(someBool.IsTrue())
-or-
if(someBool.IsFalse())
Yep! And I love them. When reading code it just becomes more obvious to me.
Comparing booleans can actually cause major problems. I recently ran into some intern code that read:
if(foo == false && bar == 2) {...}
Now, this seems pretty straight-forward, right? Just simplify it down to:
if(!foo && bar == 2) {...}
Wrong. In this case, order of operations dictates that the &&
gets evaluated first, meaning that this really evaluates to:
if(foo == (false && bar == 2))
also known as
if(!foo)
That extra thing we were supposed to be checking for, bar == 2
, is totally gone. That is why I will never, ever approve a code review that contains someBool == [true|false]
.
(You can see how the reverse statement, == true
and ||
, would also cause problems.)
Hopefully, you are using a sensible language, like VB.NET with Option Strict On, which doesn't allow coercion of other types to Boolean inside an If statement. Then there's no need to ever add the "== true" (or "= True" in VB), since the coercion case can't happen. If you want to check for non-zero then write that explicitly (ie., "If x <> 0").
Funny because I always replace code like:
if(foo) {
With:
if(true == foo) {
if(false == foo) {
But I got this habit because most of the time the code I worked with didn't have clear variable names.
One issue in C is that there's a tradition of using values other than 0 and 1 for booleans.
typedef enum { WHATEVER = 1 << 4 } MyFlags;
if (flags & WHATEVER) {
}
or even relying on -1 being true.
The problem is say you're writing an API:
struct foo {
unsigned int bar : 1;
};
void myapi_foo_set_bar(struct foo *foo, int bar) {
foo->bar = bar;
}
Here if bar isn't canonicalized to 0 or 1 it won't fit in the bitfield and it breaks:
myapi_foo_set_bar(foo, flags & WHATEVER); /* broken */
You can find other ways non-canonical bools break as well, such as comparing them to TRUE or FALSE as in the question!
Anyway what I'm coming around to is that it often makes sense to canonicalize a bool:
foo->bar = bar != FALSE;
This is a C-specific weirdness, of course.
One can develop this habit when do a lot of programming in WPF. It uses lots of bool? (nullable bool) variables to you have to write either if (someBool == true)
or if (someBool ?? false)
Consider yourself lucky, my half-monkey colleague writes
if (true)
I found it many times in his code. And that's not the worst thing I found. I found GOTOs. And we use C#. Now calm down and hold back your homicidal instincts.
if (some_flag == true)
but the implicitif (is_something)
orif (has_something)
. Note the variable names.someBool == true
is also boolean, so by the same logic it should beif ((someBool == true) == true)
.$var = (bool) some_expression
. And in most cases, it won't even matter as PHP will do the necessary conversions dynamically.