11

Possible Duplicate:
Make a big deal out of == true?

I've been looking at a lot of code samples recently, and I keep noticing the use of...

if( expression == true )
    // do something...

and...

x = ( expression == true ) ? x : y;

I've tended to always use...

x = ( expression ) ? x : y;

and...

if( expression )
    // do something...

Where == true is implicit (and obvious?)

Is this just a habit of mine, and I'm being picky about the explicit use of == true, or is it simply bad practice?

Community
  • 1
ocodo
  • 2,977

4 Answers4

17

It usually depends on the language (you can find issues around implicit boolean casting of variables in some situations).

If you're using a language like Javascript, you can have unexpected behavior in some cases (watch Douglas Crockford's Google talk - it's in there somewhere, and a good talk to watch anyway).

As there are these strange cases that can be a pain in the arse to track down and fix, I've made a point to always be explicit in my own evaluations (even using === when using a language that supports it).

The trick is to be consistent throughout your code base. When you start tossing special cases in the mix (i.e. "well, if this makes sense to me, then I'll use implicit coercion), someone's bound to get confused somewhere and start misusing it (and/or misunderstanding it). The simplest thing to do is to just stick to one rule throughout - to me, being explicit makes sense.

Demian Brecht
  • 17,585
6

Yes.

I'm going to go ahead and response with a big yes, since there are no other responses yet. But, always open to new data suggesting otherwise.

It's a yes because the expression already evaluates to a boolean. Your explicit testing of that boolean is adding nothing of value to the program. In fact, it increases the surface area for error (typos, future changes, etc).

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- Antoine de Saint-Exupery

Mark Canlas
  • 4,004
4

Yes and no.

First off, to those who say no to the situation with no exceptions, I challenge you to find a situation where a coding convention fits all use cases. This is no different.

Now in a situation where you have a simple expression being evaluated I would not add == true to the code. It is largely self explanatory and I know my coworkers would understand what is happening without much though. In addition you may fall into the debugging joy that is writing var = true rather than var == true.

while (flag) {
  // iterate
}

In a situation where you have a function inside of the comparison, unless the method is of the isSomeCondition() variety, I would add the == true. In my opinion doing so with an ambiguous method makes it more clear what you expect the code to be. After all, it is easy to miss a !.

while (largeAmbiguousCheckingMethod(input) == true) {

}

In this situation you should immediately know what the intent is, assuming a well name method, and you do not run into the problem of accidental assignment.

2

Boolean types should not require explicit testing, whereas non-boolean variables should require explicit testing.

The test condition should be thought of as a boolean itself--the result of which is either true or false. With this premise, explicit testing of a boolean is redundant and implicit testing of non-booleans is a type mis-match. Furthermore, if the coding style is consistent, an implicit test serves as a good reminder to the reader that the variable is a boolean type.

Code is read far more often than it is written so please be as kind as practical to the next person reading your code.

Sparky
  • 3,065