0

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?

RodeoClown
  • 109
  • 1
  • 1
  • 6
  • 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 '14 at 08:01
  • @BartvanIngenSchenau - depends on if some half-wit is mixing up bools with other value types like `int` or not... – James Snell Jan 31 '14 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 '14 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 '14 at 19:09
  • 1
    See also [Make a big deal out of == true?](http://programmers.stackexchange.com/questions/12807/make-a-big-deal-out-of-true) –  Feb 03 '14 at 19:01

5 Answers5

2

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.

Loren Pechtel
  • 3,371
  • 24
  • 19
  • Taking every opportunity to make small source rarely makes the output clear, just see [CodeGolf.SE](http://codegolf.stackexchange.com/) for plenty of examples. – James Snell Jan 31 '14 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 '14 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 01 '14 at 02:13
2

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"
else:
    print "'X()' evaluated to: false"

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

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

if X() is False:
    print "'X() is False' evaluated to: true"
else:
    print "'X() is 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: 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).

Thiago Silva
  • 1,039
  • 8
  • 9
1

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.

U2EF1
  • 718
  • 4
  • 5
  • This relies on the condition variable being `bool`, which depending it may not be. – James Snell Jan 31 '14 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 '14 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 '14 at 00:17
1

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.

Fred Thomsen
  • 239
  • 2
  • 7
  • 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 '14 at 06: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 '14 at 20:11
0

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

DougM
  • 6,361
  • 1
  • 17
  • 34
  • 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. :-) – Carson63000 Jan 31 '14 at 03:06
  • Good point. Changed to `recordVote(42)`. – DougM Jan 31 '14 at 03: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 05 '20 at 11:22