Is it bad to explicitly compare against boolean constants e.g. if (b == false) in Java?

Question

Is it bad to write:

if (b == false) //...

while (b != true) //...

Is it always better to instead write:

if (!b) //...

while (!b) //...

Presumably there is no difference in performance (or is there?), but how do you weigh the explicitness, the conciseness, the clarity, the readability, etc between the two?

Update

To limit the subjectivity, I'd also appreciate any quotes from authoritative coding style guidelines over which is always preferable or which to use when.

---

Note: the variable name b is just used as an example, ala foo and bar.

Answer 1

I've never seen the former except in code written by beginners; it's always the latter, and I don't think anyone is really confused by it. On the other hand, I think

int x;
...
if(x) //...

vs

if(x != 0) //...

is much more debatable, and in that case I do prefer the second

Answer 2

In my opinion it is simply annoying. Not something I would cause a ruckus over though.

Answer 3

It's not necessarily bad, it's just superfluous. Also, the actual variable name weights a lot. I would prefer for example if (userIsAllowedToLogin) above if (b) or even worse if (flag).

As to the performance concern, the compiler optimizes it away at any way.

Update: as to the authoritative sources, I can't find something explicitly in the Sun Coding Conventions, but at least Checkstyle has a SimplifyBooleanExpression module which would warn about that.

Answer 4

I prefer the first, because it's clearer. The machine can read either equally well, but I try to write code for other people to read, not just the machine.

Answer 5

IMO, yes you should should not use the first style. I have seen people use:

if ( b == true ) 
or 
if ( b == false )

I personally find it hard to read but it is passable. However, a big problem I have with that style is that it leads to the incredibly counter-intuitive example you showed:

if ( b != true )
or
if (b != false )

That takes more effort on the part of the reader to determine the authors intent. Personally, I find including an explicit comparison to true or false to be redundant and thus harder to read, but that's me.

Answer 6

Usually I prefer the ! form, but:

1. if (obscureFcn("file") == false)

2. if (!obscureFcn("file"))

The first way tells you that obscureFcn() returns bool, you don't even have to think about it. The second could be int, char, some kind of pointer, etc. One night at 5am when you're debugging a production crash you'll be so glad you took the more verbose option!

(I realize that the recommended form of [2] is if (obscureFcn() == 0), but that's one I find verbose.)

Answer 7

The overriding reason why you shouldn't use the first style is because both of these are valid:

if (b = false) //...

while (b = true) //...

That is, if you accidentally leave out one character, you create an assignment instead of a comparison. An assignment expression evaluates to the value that was assigned, so the first statement above assigns the value false to b and evaluates to false. The second assigns true to b, so it always evaluates to true, no matter what you do with b inside the loop.

Answer 8

IMHO, I think if you just make the bool variable names prepended with "Is", it will be self evident and more meaningful and then, you can remove the explicit comparison with true or false

Example:

isEdited  // use IsEdited in case of property names
isAuthorized // use IsAuthorized in case of property names

etc

Answer 9

This is strongly a matter of taste.

Personally I've found that (!a) is a lot less readable than (a == false) and hence more error prone when maintaining the code later, and I've converted to use the latter form.

Basically I dislike the choice of symbols for logic operations instead of words (C versus Pascal), because to me a = 10 and not b = 20 reads easier than a == 10 && !(b==20), but that is the way it is in Java.

Anybody who puts the "== false" approach down in favour of "!" clearly never had stared at code for too long and missed that exclamation mark. Yes you can get code-blind.

Answer 10

Personally, I would refactor the code so I am not using a negative test. for example.

if (b == false) {
   // false
} else {
   // true
}

or

boolean b = false;
while(b == false) {
  if (condition)
      b = true;
}

IMHO, In 90% of cases, code can be refactored so the negative test is not required.

Answer 11

I would say it is bad.

while (!b) {
    // do something 
}

reads much better than

while (b != true) {
    // do something 
}