Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

I'm moving over to work on a library that a fellow developer has been writing. It's full of == true and == false, which I find crazy frustrating to read.

I've tried asking him to quit doing it, but he just says that it makes it more straightforward to understand what is going on. Is there a good reason why this isn't a great practice? Or is it purely a stylistic thing?

share|improve this question

marked as duplicate by delnan, gnat, Kilian Foth, MichaelT, amon Feb 3 at 17:33

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

3  
As operator== yields a boolean value itself, your followup question should be: "Don't you think writing (bBool == true) == true makes the code even more straightforward to understand? Why don't you use that style?". –  Bart van Ingen Schenau Jan 31 at 8:01
    
@BartvanIngenSchenau - depends on if some half-wit is mixing up bools with other value types like int or not... –  James Snell Jan 31 at 11:19
    
@JamesSnell: Would you really recommend (anInt == 0) == true? I agree that for numeric results you should have an explicit test. What I said is that if you require explicit tests for operations that result in a boolean value, then you should apply that exact same logic to the result of operator==. –  Bart van Ingen Schenau Jan 31 at 13:35
    
No, I'm saying that there are too many "programmers" who don't understand basic type safety, get their types mixed up and test for !anInt with unexpected results... –  James Snell Jan 31 at 19:09
1  
See also Make a big deal out of == true? –  MichaelT Feb 3 at 19:01

5 Answers 5

The bigger the code the more time it takes to read and the more chance you have to misunderstand something.

== true is 7 characters that contribute nothing to the code and thus is pure cost, no benefit.

I wouldn't be so harsh on == false, though. You can make an argument between negation and a comparison to false, while you can argue negation is superior it's not absolutely trumped like in the == true case.

share|improve this answer
    
Taking every opportunity to make small source rarely makes the output clear, just see CodeGolf.SE for plenty of examples. –  James Snell Jan 31 at 11:27
    
If you're trying your best to use the least characters possible, then it's code obfuscation and not maintainable code. –  Brendan Jan 31 at 14:22
    
I don't support taking EVERY opportunity to make code shorter. It's just I feel you lose absolutely nothing by removing the == true. –  Loren Pechtel Feb 1 at 2:13

I too find this frustrating, up there with

if (condition)
    return true;
else
    return false;

It indicates to me a lack of understanding of what booleans do. Any additional complexity in code is a potential source of bugs, although this one is trivial enough I could put it off to stylistic differences. You can get used to anything.

share|improve this answer
    
This relies on the condition variable being bool, which depending it may not be. –  James Snell Jan 31 at 11:24
    
@JamesSnell Usually the condition is more complicated than a single variable. If it is not, I'd still prefer something like return bool(condition). –  U2EF1 Jan 31 at 11:58
    
That style of if statement makes semantic sense, IMHO, in cases where the semantic meaning of the function's return differs from that of the condition being tested. For example, if a true return means an operation succeeded and a false return means it failed, literal return true and return false show success and failure more clearly than return sz == fwrite(f, 1, sz, b); They may also be easily adapted in case some other success/failure mechanism is desired. –  supercat Feb 25 at 0:17

I agree with your point, and I too find it frustrating to read; however, when you have a lone negated if condition like so:

if(!condition)
    doThis();

I've been told by a few senior devs that it can be easy to miss the negation operator when reviewing code and they prefer to see:

if(condition == false)
    doThis();

I agree with you that it is too verbose; however, it seems that in some instances like the one I described, some people would rather have that.

share|improve this answer
    
That's why I felt you can't make nearly as strong a case against == false as you can against == true. –  Loren Pechtel Jan 31 at 6:10
    
I'd rather use a bit of extra whitespace there to make the ! more visible (like code complete suggests). So if( !condition ), or something like it. –  RodeoClown Jan 31 at 20:11

Depending on the language, the semantics are not so trivial. In Python:

class X:
   def __cmp__(self, other):
       return 0
   def __nonzero__(self):
       return False

if X():
    print "X() evaluated to true"
else:
    print "X() evaluated to false"

if X() == False:
    print "X() == False evaluated to true"
else:
    print "X() == False evaluated to false"

if X() is None:
    print "X() is None evaluated to true"
else:
    print "X() is None evaluated to false"

prints

X() evaluated to false
X() == False evaluated to true
X() is None evaluated to false

Certainly one can make a case, even in python, for ignoring the operator. The problem is that it may be misleading for who wrote the code ("python must be just like [whatever-language], so I'll leave the equality operator implicit") and for who reads it ("was he really intending to eq compare implicitly or should it be an explicit is?").

It is very time consuming to track down bugs caused by implicit boolean checks that should be explicit (and correct).

share|improve this answer
    
A great example of how mixing value types can lead people to become quite unstuck. Nice answer. –  James Snell Jan 31 at 11:23

It isn't, in general. For compiled languages the expression will be likely reduced to the same machine code, and in interpreted languages the explicit test will help reduce the chance of unwanted code insertion.

Consider the following JavaScript function, to, say, tally votes on a hypothetical ballot measure.

function recordVote(YesOrNo) {
  if(YesOrNo == true) {
    voteYes();
  } elseif (YesOrNo == false) {
    voteNo();
  }
}

If you call recordVote(true) or recordVote(false), the interior method fires as expected. And, if you improperly call recordVote(42), recordVote(null), or recordVote("false"), you get no action -- which is desired for a voting app. (especially since the standard test for truthyness, of if(YesOrNo), would cause that last one to record a vote incorrectly.


Of course, note that the small benefits you get from the above are inferior to consistency in your code. If the library's already full of them, don't remove them -- but don't add them if it isn't. (Unless, of course, you're refactoring everything anyway and have some arbitrary style rule to force your source code to be as small as possible...)

share|improve this answer
1  
Actually, calling e.g. recordVote(1) will record a Yes vote. You need to use the triple-equals comparison if(YesOrNo === true) to avoid the 1 being implicitly converted to true. :-) –  Carson63000 Jan 31 at 3:06
    
Good point. Changed to recordVote(42). –  DougM Jan 31 at 3:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.