This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

12

I prefer the explicit if (some_flag == true) but the implicit if (is_something) or if (has_something). Note the variable names.
–
fredoverflowOct 18 '10 at 21:44

69

Remind your colleague that the type of someBool == true is also boolean, so by the same logic it should be if ((someBool == true) == true).
–
Mike SeymourOct 19 '10 at 0:00

2

@GSto: I suppose you know it, but in PHP you can do that to "cast" anything to a bool and can be actually useful.
–
zneakOct 19 '10 at 2:21

2

@zneak Or you could be clearer and use $var = (bool) some_expression. And in most cases, it won't even matter as PHP will do the necessary conversions dynamically.
–
waiwai933Oct 19 '10 at 3:15

When I see someBool == true, I can't help but feel like the programmer hasn't internalized the idea of evaluation, which is a pretty fundamental deficiency.

However, my perspective is skewed because I spent several summers in college teaching programming to kids, who frequently wrote expressions like this because they genuinely hadn't mastered the mental exercise of evaluating an expression. Once they grokked the concept, the redundancy became obvious.

For an otherwise competent professional programmer, this is probably not the case. It's probably just a bad habit they developed in their early days of programming and never quite shook. But it would still scare me a bit if it was the first thing I saw someone do in an interview.

Sometimes I would write if (c == true) return true; else return false;, but 99% of the time (the 1% is there since I can never be sure that I didn't miss some) I'll immediately notice and replace the whole thing with return c. I'll expect most competent programmers should do something similar if they developed the habit early on their career. What I wouldn't expect is a wtf response.
–
Lie RyanOct 19 '10 at 11:54

1

Oh boy, the art of thinking. I literally came across this in our codebase last week. if (!someCondition) { someCondition = false; } I've seen some (er, many) redundancies as well as some impossibilities in our code, but this one was so simple yet so aggravating to think that somebody actually wrote it. Multiple times, even.
–
Anthony PegramOct 20 '10 at 19:26

1

Just note that I have seen a few cases of if(x) x=true; which were NOT redundant, but rather the equivalent of x=!!x; (normalizing x to 0/1)
–
jkerianOct 20 '10 at 20:02

Yeah, agreed. It's silly, but you gotta pick your fights, and this code is indeed doing what your colleague things it will. Mention it in a non-"What the hell is WRONG with you?!" kind of way, then drop it. Though if they start pulling crap like "if (someBool != true)" or "if (!someBool == true)" or other such convolutions, that might be a fight worth picking....
–
BlairHippoOct 18 '10 at 20:11

3

How is (someBool == false) any worse than if (someBool == true)?
–
FinnNkOct 18 '10 at 20:16

5

true=true does not compile, you cannot assign to true ;-)
–
fredoverflowOct 18 '10 at 21:41

1

I've gotten used to if(somebool == false) or !=, but always against false and not true. I find it redundant, but since the coding standard insists that if() looks like a function call the whitespace between the parens helps me read it. On my own, a bool is a bool, but if (somePointer) doesn't fly; I prefer if (somePointer != NULL) since a pointer is not a bool.
–
dash-tom-bangOct 18 '10 at 23:05

Well put, its good to strive for perfection but surely there are bigger fish to fry
–
TJBOct 19 '10 at 3:43

3

I think you say this about every problem that merits discussion.
–
Dave Van den EyndeOct 19 '10 at 6:40

2

It's potentially indicative of much larger problems. A small brown stain on the ceiling in your garage may not seem like a big deal, but it could mean you have a major water leak.
–
JoshOct 19 '10 at 12:52

This isn't a relevant argument. If you're working in a language like that, you could just move the true to the other side. The question is about whether or not to include the true at all.
–
CamOct 18 '10 at 20:18

8

@Cam: Missing the point are you. Backwards logic I not am suggesting.
–
GuffaOct 18 '10 at 20:36

15

@Cam - He is giving a real world example of when this can be a problem. I would say this is quite relevant.
–
ChaosPandionOct 18 '10 at 20:39

1

@Guffa Cam is very right. This is not a reason to stop using == (anyType) in if blocks.
–
Ronny BrendelOct 19 '10 at 8:10

2

@Ronny: No, it can't happen with any type (unless the language actually allows any type as a condition). The statement if (answer = 42) {} simply doesn't compile because the expression is not a bool.
–
GuffaOct 19 '10 at 14:08

Depending on the language and the variable's name, x==true is appropriate:

Consider the following situation in a language with static typing and type coercion for integral types:

if (actionsAllowed){
//do actions, since they are allowed
//...
}

Someone reading this section of the code might not realize immediately that actionsAllowed is a boolean variable - it could also be an integer, representing the number of allowed actions. So by adding == true, it becomes clear that x is a boolean, and not an integer being coerced to a boolean:

if (actionsAllowed == true){
//do actions, since they are allowed
//...
}

Typically, you don't want to make a big deal out of coding conventions unless said convention is somehow impeding the project in a significant way. I've seen many a heated argument escalate over things as small as code regions and leading underscores.

That being said, I see no issue with adding == true to a conditional statement. As a matter of fact, I am in the habit of using == false as opposed to a leading exclamation point when testing for negative conditions. I think it's more readable.

If there is an established convention, I say follow it unless there is reason to change. However, it's not really worth raising a big stink about.

Depending on your language, someValue might not necessarily be the equivalent of true even if it evaluates to true. For instance, (9 == True) evaluates to false in Python and I would imagine similar in C++.
–
dash-tom-bangOct 18 '10 at 23:06

Ack. I'm that guy. The shame, the shame. It's how I learned, and it's how I "auto-format" in my head. The only time I use Joel's prefered syntax is when the bool variable has a verb prefix like "is." I need the verb, be it "is," "can," "did," or else I need the == to provide the verb "equals." I might never break that habit, so I'll understand if you don't say 'hello' to me on the street.

C++ actually has the not operator, and so does C (once you include the standard header <iso646.h>). If you don’t want to (or can’t) use this header (or if you’re stuck with Java or C#), I suggest putting a space after the exclamation mark: if (! condition). This makes it somewhat more conspicuous.
–
Konrad RudolphOct 21 '10 at 7:28

It's not just redundant in C++, it's dangerous. If you write if (b == true), and b isn't a bool, the type conversions go the wrong way. A bool is an integral type that is normally promoted to an appropriate integral type with value 1. If you write, say, int b(2); if (b == true) then true becomes an int with value 1 for purposes of the comparison, rather than b being coerced into type bool, which would give the right result.
–
David ThornleyOct 19 '10 at 18:02

"if bla == true" reads like a sentence, where as "if bla" does not in many cases. It just sounds wrong, when READING actual code.

Also the compiler warns about assignments in if blocks, so there is really no danger in using == true. (confusing it with =)

Also do guys that don't write "== true", use that "!()" for "== false"? I find it really ugly. And if you use "== false", it is only very consistent to also use "== true", instead of having two distinct ways of verifying truth.

If tristate is not a problem, then there usually should not be a reason to compare something to true/True. However, in Python and several other languages such as C/C++ you can perform an if on a non-bool expression. These languages have unique rules for interpreting integers, pointers, lists, etc. as either true or false. Sometime you do not want that. For example, in this Python snippet:

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

Here z should be True, but z2 should be False. Now, a Clojure language approaches this in yet another way - there and function does not necessarily evaluate to a bool, but the if can handle that.

Regardless of the language, any time you find yourself comparing something to True or False, it is probably worth commenting.

Such coding would have rubbed me the wrong way before too. Although your example identifier is named "someBool", using that coding style inadvertently on a variable which wasn't guaranteed to be a boolean could have unintended behavior. If the value of "someBool" isn't exactly "true" or "false", the result will be false.

I encountered a very subtle bug this past year caused by such a coding style which was difficult to identify because one's eyes gloss over such constructs. You'd think, "How could it be wrong?" The same holds true for such well-understood expressions as "(var)" or "(!var)", that you read or code them without verifying their behavior.

So I've introduced a couple of coding standards to reduce the existence of such bugs in the codebase and the likelihood that such subtle bugs will accidentally creep in sometime in the future.

All expressions must be parenthesized per their intent.

All boolean tests must be expressed in the negative, like "suchBool != false".

By cleaning up code not conforming to the new style, I've identified and corrected a few more instances of such subtle bugs.

To add another misuse of booleans, I have found this kind of construction a bunch of times in Javascript, (specially at some spaghetti-like monster functions, as in 100+ lines):

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example
flag=$("mycheckbox").selected;
//...
//and at the moment of use it:
if(flag!=true) {
//code to execute when the checkbox is unchecked
}

It seems, that due to the lack of an strict type definition in this language, some programmers prefer not have to be messing around with the false|undefined values.

I'd say consistency is king in a codebase. So you should use the style, that is mostly used in your organization. Try to make your preferred style part of official company coding guidelines. If it's already in the guidelines, just follow it.

(That being said, it would also really annoy me - but probably not enough to make a big deal out of it).

I prefer not placing the extra == true, but sometimes I accidentally include it and don't notice it. The person may not have noticed and accidentally placed them. I reread my code and sometimes notice that I placed the extra == true so I remove that == true. I sometimes don't notice it and would happily welcome someone telling me I placed it redundantly.