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?

  • 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?". Jan 31, 2014 at 8:01
  • @BartvanIngenSchenau - depends on if some half-wit is mixing up bools with other value types like int or not... Jan 31, 2014 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==. Jan 31, 2014 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... Jan 31, 2014 at 19:09
  • 1
    See also Make a big deal out of == true?
    – user40980
    Feb 3, 2014 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.

  • Taking every opportunity to make small source rarely makes the output clear, just see CodeGolf.SE for plenty of examples. Jan 31, 2014 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, 2014 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. Feb 1, 2014 at 2:13

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

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

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

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

if X() == 0:
    print "'X() == 0' evaluated to: true"
    print "'X() == 0' evaluated to: false"

if X() is False:
    print "'X() is False' evaluated to: true"
    print "'X() is False' evaluated to: false"

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


'X()' evaluated to: false
'X() == False' evaluated to: false
'X() == 0' evaluated to: false
'X() is False' evaluated to: false
'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).

  • 1
    A great example of how mixing value types can lead people to become quite unstuck. Nice answer. Jan 31, 2014 at 11:23

I too find this frustrating, up there with

if (condition)
    return true;
    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.

  • This relies on the condition variable being bool, which depending it may not be. Jan 31, 2014 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, 2014 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, 2014 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:


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)

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.

  • That's why I felt you can't make nearly as strong a case against == false as you can against == true. Jan 31, 2014 at 6:10
  • 1
    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, 2014 at 20:11

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) {
  } elseif (YesOrNo == false) {

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...)

  • 2
    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. :-) Jan 31, 2014 at 3:06
  • Good point. Changed to recordVote(42).
    – DougM
    Jan 31, 2014 at 3:08
  • @DougM Carson's point was that == is wrong according to the point you try to make. Changing the input value doesn't fix the problem.
    – Florian F
    Aug 5, 2020 at 11:22

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