Why (boolean == true) type of comparisons should be avoided


Java has quite a big impact on its syntax/design by C/C++. Both the languages share quite a bit of syntax and ideas. But the designers of Java made the language strict and tightened it up significantly.

Lets focus our discussion on booleans. In C/C++ zero (0) is treated as false and anything except zero (1) is treated as true. This caused a lot of bugs that were not found at compile time, especially with assignment vs. comparison. Here is a code snippet for elaboration:

int i = number;
if ( i == 5 ) {
// do something
}

in C/C++ it is pretty easy to write the same code as:

int i = number;
if ( i = 5 ) { // note that there is an assignment involved here instead of a comparison
// do something
}

in C/C++ This will have the effect of assigning 5 to “i”, regardless of what “number” was equal to, the result will be non-zero, i.e. true, and after this code, “i” would equal 5.

In Java, we now have the “boolean” type which is either “true” or “false”. The parameter to the “if” statement has to be “boolean”, rather than an int as in C/C++. The code assigning 5 to i would not compile in Java. This is great, because we can now find a lot of bugs at compile time.

BUT When we assign one boolean to another, the returned value is that of the value we are assigning to. This means that the bug mentioned above is still possible if we are doing boolean comparisons! I have often seen code such as the following, even from experienced, otherwise good, Java programmers (I counted over 1000 occurrences in the project I was working on).

boolean b = false;
if ( b == true ) {
System.Out.println( “All hell doesn't broke lose.” );
}

But the same code can easily be written as:

boolean b = false;
if ( b = true ) {
System.Out.println( “All hell WILL broke lose.” );
}

This will not only compile fine in java but all hell will also break lose. So in my opinion its best to write the same piece of code as:

boolean b = false;
if ( b ) {
System.out.println( “All hell broke lose.” );
}

Also the Microsoft guys (very common with C/C++ programmers) came up with a little coding convention for their C/C++ code for these situations as:

int i = number;
if ( 5 == i ) {
// do something
}

This technique is safe as you cannot assign a variable or anything to a constant. My little secret when I used to interview people for C/C++ jobs I always gave them some type of code involving such comparisons and would keep an eye on how do they write their conditions to get an idea bout how much they have coded and how much pain they have suffered from having such bugs in the code. Anyways this technique is same as the if ( bool ) check.

It is pretty easy for a bug like this to slip in during maintenance. So we should keep an eye out for less careful future programmers who will be maintaining the code that we once wrote.

Advertisements
Why (boolean == true) type of comparisons should be avoided

7 thoughts on “Why (boolean == true) type of comparisons should be avoided

  1. uXuf says:

    I’d think you are working with some highly (in)competent (inexperienced?) people if you can count over a thousand occurrences of the assignment-versus-evaluation problem! Talk to them before it gets out of hand, think about the places that you have not eyeballed yet!

    1. Faisal Feroz says:

      Well I guess you miss read the post. I counted over 1000 instances of boolean == true type of checks in the code. I have edited the post to make it more clear.

      I bet not many programmers knows that the assignment-versus-comparison bug is possible in type safe languages like .Net and Java (although for booleans only).

      The point of the post is to discuss why boolean comparison with true/false can cause problems. This is not a flame post discussing the experience and/or caliber of the programmers in team 🙂

  2. DeViL says:

    Another small pick in Faisal’s approach is that you are saving an unnecessary comparison when you use if(b) instead of if(b==true).

    This might not be a point of worry for small applications but when it comes to million of transactions, this really matters.

  3. DeViL says:

    Another small pick in Faisal’s approach is that you are saving an unnecessary comparison when you use if(b) instead of if(b==true).

    This might not be a point of worry for small applications but when it comes to millions of transactions, this really matters.

  4. Hans says:

    There is one more reason not to compare with “true” in C. It is useful that anything non-zero is considered true in C. Suppose that we have a status register with many bits, and we want to check one of them. This is easy in C, just do “if(status_reg & MY_BIT_MASK)”.

    Code like “if((status_reg & BIT_MASK) == true” will fail. I have seen people do stuff like “if((status_reg >> bit_number) & 1) == true”, and I don’t like it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s