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,948
  • 3
  • 23
  • 31
  • For me it depends. Sometimes in Java When I'm given a possibly null Boolean (we'll call x) I'll write `if (x == null || x == true)` because I think it's easier to read than `if (x == null || x)` or `if(x != false)`. Of course depending on the specification i might have `x != null` etc. – WuHoUnited Nov 15 '11 at 23:51
  • 1
    I would argue that programming languages that insist on using `== true` are lacking in logical simplicity. – Bernard Nov 16 '11 at 00:24
  • 3
    It is hardly worth thinking about. There are SO MANY MUCH WORSE things than "x == True" as far as readability is concerned. If thats the worst thing you find on any given day consider yourself lucky. – Angelo Nov 16 '11 at 01:22

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,555
  • 1
  • 47
  • 81
  • 3
    +1 I personally prefer implicit (less code is normally better), however consistent code is by far the most important thing – Tom Squires Nov 15 '11 at 23:51
  • What's icky with C and NULL? Of all the languages I've used, I like its handling of true/false the best. More weakly-type languages (PHP, JavaScript) do some unintuitive things, and strongly-typed languages are annoying. – Austin Nov 16 '11 at 00:14
  • Nothing, it doesn't matter what it points to, it's not being dereferenced. if(c) and if(*c) mean different things. – Austin Nov 16 '11 at 01:25
  • 1
    @DemianBrecht: The condition will evaluate to true, since the pointer isn't NULL. Nothing unintuitive about that. – Hippo Nov 16 '11 at 01:26
  • @Austin, Hippo: Yep, I'm dumb.. Been a long day. I **do** remember running into horrendous issues before (release builds usually), but I can't remember offhand now what, exactly, they were. – Demian Brecht Nov 16 '11 at 01:42
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
  • 3,986
  • 1
  • 29
  • 36
  • 1
    +1 It is especially obvious when the expression is a well named method e.g. `if (dog.isBarking()) { // tell it to shut up }` so for better readability keep [replace temp with query](http://sourcemaking.com/refactoring/replace-temp-with-query) in mind. – Gyan aka Gary Buyn Nov 15 '11 at 23:23
  • 6
    -1. It does generally evaluate to a Boolean, but usually through implicit casting that uses rules that are often much less strict than the rest of the language. One can enforce that the argument is actually a Boolean using the `== TRUE` form, avoiding these loose implicit casting rules. In a type-safer language (like Haskell), I wouldn't bother with the `== TRUE`, but in most mainstream languages, I think it works around language shortcomings. – Aidan Cully Nov 15 '11 at 23:31
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,055
  • 18
  • 18