Does if (myBool == true) differ computational wise to if(myBool)?

Question

I read a coding style suggestion about comparing bools that said to write

if (myBoolValue == true) { ... }
if (myBoolValue == false) { ... }

instead of writing

if (myBoolValue) { ... }
if (!myBoolValue) { ... }

since it increases readability of the code even though they are equivalent statements. I am well aware that it is not a usual coding practice but I will agree that it may increase readability in some cases.

My question is if there is any difference between the two in regards of optimization of code execution or if (a well implemented) compiler translate them to the same thing?

Answer 1

The productions are not the same in all languages.

For instance, they may produce different results for some "non-boolean" values of "myBoolValue" in both JavaScript and C.

// JavaScript
[] == true         // false
[] ? true : false  // true

// C
#define true 1
#define false 0
int x = -1;
x == true         // 0 (false)
x ? true : false  // true (1)

To see what a specific compiler does for a specific programming language (there is both what it is allowed to do and then what it will do), check the generated assembly/machine/byte code.

(Anyway, I prefer and use the latter form exclusively.)

Answer 2

Apart from cases like JavaScript and I guess Java with autoboxing and Boolean, where the semantics can differ between the two forms, it really depends on compiler optimization.

I never understand this recommendation. If myBool is a boolean, so is (myBool == true), so why doesn't it require ((myBool == true) == true), and so on forever? Where does this stop? Surely the answer is not to start in the first place?

Surely the more there is to read, the less readable it is?

Answer 3

In C (and many other languages) there's no boolean type, all are numeric expression, so myBoolValue may be equal to 2 or any value different from 0 and 1, and comparing them numerically won't give you the correct result.

#define true 1
#define false 0
if (5 == true) //...

To improve readability, name the variable meaningful (such as isNonZero, isInGoodState, isClosed, LoopEnded...) rather than comparing them with true

Another way is comparing them with 0 or false when you need the true case (myBoolValue != false). Also, using bool type (if it's available) may solve some problems.

Answer 4

The behavior depends on the language and on the type of the value being tested. The two forms are not equivalent in all cases.

In C, conditions are commonly represented using integers, with 0 being treated as false and any non-zero value being treated as true. Comparing such a value for equality to true is invalid; for example, if the value happens to be 2 or -1, it's logically true but not equal to true. As of C99, C does have a built-in boolean type called _Bool, aliased as bool if you have #include <stdbool.h>. But it's still common to use other types, particularly int to represent conditions, and even to redefine bool, false, and true in various ways.

C++ has has a built-in bool type, with false and true literals, since very early in its development, but it still retains much of its C ancestry. Other C-inspired languages are likely to have similar issues.

In languages that have a built-in boolean type and don't allow values of other types to be used directly as conditions, if (x) and if (x == true) are more likely to be equivalent. And if they're semantically equivalent, I would expect any decent optimizing compiler to generate the same code for either form, or very nearly so.

But I strongly disagree with the style advice. An explicit comparison to false or true, even in cases where it's equivalent to testing the value directly, do not IMHO aid readability.

If you have a variable whose value denotes a condition, it's more important to give it a name that indicates that. Programming language code shouldn't necessarily follow English grammar, but something like

if (file_is_open)

is not made more readable by changing it to

if (file_is_open == true)

As a C programmer, I like to write my conditions more explicitly than a lot of other programmers do; I'll write if (ptr != NULL) rather than if (ptr), and if (c != '\0') rather than if (c). But if a variable is already a condition, I see no point in adding a superfluous comparison.

And value == true is itself a condition; if if (value == true) is supposed to be more readable than if (value), why wouldn't if ((value == true) == true) be even better?