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.

There is a colleague of mine who constantly writes:

if (someBool == true)

It drives me up the wall! Should I make a big deal of it or just drop it?

share

locked by Yannis Rizos Mar 13 '12 at 20:42

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. –  FredOverflow Oct 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 Seymour Oct 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. –  zneak Oct 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. –  waiwai933 Oct 19 '10 at 3:15
4  
always check the constant first, if (true == someBool), in case you accidentally typed = instead of == [yes i'm kidding!] –  Steven A. Lowe Oct 19 '10 at 17:45

47 Answers 47

That drives me crazy too, but I'd say mention the redundancy to them in a constructive way and then drop it even if they don't concur.

Alternatively you could try this approach:
You: Can you start using the following code convention for evaluating Booleans?

if (someBool==true)&&(true==true) {}

Them: Why would we do that? The second half of that statement is redundant, it would always evaluate to true.

You: By George, you are right. Silly me. Let's just go with a version without all the redundancy then. How about?

if (someBool) {}
share
6  
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.... –  BlairHippo Oct 18 '10 at 20:11
3  
How is (someBool == false) any worse than if (someBool == true)? –  FinnNk Oct 18 '10 at 20:16
5  
true=true does not compile, you cannot assign to true ;-) –  FredOverflow Oct 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-bang Oct 18 '10 at 23:05
5  
It's about readability, not illogic or (micro)-redundancy –  Ronny Brendel Oct 19 '10 at 8:14

I prefer

if (bVal)

or

if (!bVal)

too, but I'm afraid that bringing it up would piss people off, so my advice is to forget it. Sorry!

share
4  
For the love of all that is holy, as long as it's not if (!bNotVal) or if (bNotVal) even in the first place. Ugh negatives in names makes everything harder to read. –  dash-tom-bang Oct 18 '10 at 23:48
2  
I knew a dev who would bool isNotConnected; if (isNotConnected==true) ... yuck –  johnc Oct 19 '10 at 2:04

Generally will omit the '== true', but it's hardly worth even a minute discussing it unless you have it included in your team's coding standards.

share
3  
Also, if it is in the team's coding standards, you really need to re-evaluate the standards to get rid of trivia like this. –  JohnFx Oct 18 '10 at 20:11

It's only redundant code, not life or death. However....

If it's happening a lot, it could be a problem with how someBool is being named. A good name can go a long way towards eliminating the need for the ==true

if(IsSomeCondition)

or

if(hasCondition)

or

if(somethingExists)

for example.

share
2  
Beat me to it! Without appropriate naming, the more succinct equivalency makes no sense at all. –  Troy Hunt Oct 19 '10 at 3:42
4  
I have had to used someBool == true for legacy code several times for clarity. But if I write from scratch I name the variable accordingly and use if (isSomething) –  nimcap Oct 19 '10 at 6:38

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

share

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.

share
1  
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-bang Oct 18 '10 at 23:06

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.

share

You should definitely stop this bad habit. Gently...

It's easy to forget to write the double equal signs, turning the code into:

if (someBool = true)

In C# for example this will only produce a warning, not an error. So unless you treat warnings as errors the code will run, set the variable to true and always enter the condition.

share
6  
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. –  Cam Oct 18 '10 at 20:18
8  
@Cam: Missing the point are you. Backwards logic I not am suggesting. –  Guffa Oct 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. –  ChaosPandion Oct 18 '10 at 20:39
1  
@Guffa Cam is very right. This is not a reason to stop using == (anyType) in if blocks. –  Ronny Brendel Oct 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. –  Guffa Oct 19 '10 at 14:08

I agree with you, but I'm going to play devil's advocate here:


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
    //...
}
share
13  
readability == GoodThing –  Muad'Dib Oct 18 '10 at 20:18
5  
if ((readability == GoodThing) == true) ... –  JoelFan Oct 18 '10 at 20:42
1  
bool isGoodThing = readibility?true:(codingStandards?true:(internalizationOfConcept?true:false)); –  johnc Oct 19 '10 at 2:02
17  
So rename the variable actionsAreAllowed. –  Graeme Perrow Oct 19 '10 at 3:13
9  
By writing if (x) { ... you are already asserting that x is a boolean or is convertible to a boolean. What you call it is irrelevant. –  Daniel Earwicker Oct 19 '10 at 10:28

I think that, if something so trivial is your biggest problem with your co-workers, you should consider yourself pretty lucky.

share
5  
Well put, its good to strive for perfection but surely there are bigger fish to fry –  TJB Oct 19 '10 at 3:43
3  
I think you say this about every problem that merits discussion. –  Dave Van den Eynde Oct 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. –  Josh Oct 19 '10 at 12:52

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.

share
12  
Agree wholeheartedly about evaluation. On occassion I've wondered, "Where does it stop?" if ((((x == true) == true) == true) != false) // and so on... –  yawmark Oct 19 '10 at 3:52
1  
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 Ryan Oct 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 Pegram Oct 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) –  jkerian Oct 20 '10 at 20:02

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.

  1. All expressions must be parenthesized per their intent.
  2. 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.

share
1  
Having some someBool able to be something other than TRUE/FALSE is bad coding practice. –  AttackingHobo Oct 19 '10 at 0:20

how about:

int j = 1;
for (int i=1; i>=j; i++) ...

Yep, I've seen it.

share

What about nullable bools?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 
share
1  
Not all languages have nullable bools, and many of those that do will accept your second construct. –  zneak Oct 19 '10 at 2:30
1  
@johnc: "if (MyFlag.Value)" may not really do what you want it to as it can throw an exception if MyFlag is null (which you can test by checking MyFlag.HasValue). –  Ludovic Oct 19 '10 at 3:36
4  
This is my pet peeve with nullable bools :) –  Jarrod Dixon Oct 19 '10 at 4:48
3  
bool? isValid = null; if (isValid ?? false) ; –  skolima Oct 19 '10 at 5:47

It depends on the language, but it's usually a bad idea...

In C, never do this. It's too easy to find a situation where the value you are testing is not false (non-zero), but also not equal to the single value defined as "true".

In Ruby, do this only if you are absolutely certain that you want to fail on everything except Boolean true.

In C++ and other static languages with a bool type, it's redundant, and can lead to programming errors when you mis-type = instead of ==, or promotion errors as mentioned in the comments.

share
4  
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 Thornley Oct 19 '10 at 18:02

It's a code smell for a novice developer. They have yet to master/internalize the boolean condition and must explicitly evaluate to the true or false condition.

share

In JavaScript, I prefer if(bool) when I have sufficient documentation explaining what the method expects... but when evaluation of true can mean the variable exists, equals the number 1 or the boolean true, it's tougher.

Strongly typing in JS also means less flexibility. Tough call. Strongly typed languages, lay down the hammer. Otherwise, ask why he does it?

Actually, there's your answer: ask him why. Then correct him.

share

How about

if (x == "true")

WHY IS THAT A STRING?!

share
4  
yea, I also see if (x == "1"), but that's usually do to poor db design. –  atfergs Oct 19 '10 at 12:53

Had to use this all the time in ActionScript 2 (admittedly now a dead language), because:

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

So it was almost always best to be specific.

share

While I agree as a mainly C# developer, I can't say this is always the case. For instance, in Javascript, the === will perform type coalescence. So assuming var x = 3 then:

if(x) --> true

while

if (x === true) --> false

I guess that's different than == since even in JS I wouldn't use if(x == true) but just something to think about.

This sort of touches on another point though which has come up in my office:

bool b = false;

In C#, bool b; would be enough and would initalize b to false. However, it is more explicit to write the above line and anyway should be ripped out by the compiler during optimization.

So I guess my point is it's not always so obvious what is and isn't good practice and a lot of it boils down to preference as well as language features/quirks.

share

Actually, if it's nullable, testing for x == true would be necessary. :)

share

use it as an opportunity to teach him. he will respect you more if you do. wouldn't you want someone to do the same for you?

share

Research shows that code with many redundancies correlates strongly with errors. Here's an interesting paper on the matter (PDF alert).

share

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.

share
7  
It is not a bad thing. Code that reads like real text is far better, than implicit foo. Keep that habit for the sake of readability. –  Ronny Brendel Oct 19 '10 at 8:18

you should tell him that he is doing it wrong.

its

if (true == someBool) {

}

if he ever forget one = he is in big trouble in his writing style.

share

Yes, This is a kind of programmers mind set. All the time they considers "if condition" has no existence with out an expression with symbols =,<,>... I've seen situations people really get struggle as like "function return"

if(RowsAffected > 0) { return true; } else { return false; }

Programmers need to watch their code from the real time angle.. :)

share
1  
That means their understanding of the language is lacking, which is a real problem –  JoelFan Oct 19 '10 at 13:14

I write code like that!

Here is why:

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

share
3  
You say "if bla" does not read like a sentence... that means your variable is not named properly... what's wrong with this: if (userHasRights) doSomething() –  JoelFan Oct 19 '10 at 13:13

Personally, I strongly dislike the way to say "not" in C based languages. That little exclamation mark is too easy to overlook.

Hence I write it out in full:

if (someCondition == false) {

After reading that for a while, I want symmetry too with

if (someCondition == true) {

So consider it an artifact of C using ! instead of not.

share
3  
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 Rudolph Oct 21 '10 at 7:28
1  
I do Java. not is not an option. –  user1249 Oct 21 '10 at 8:13

Yes, it's a big deal because the name of the boolean should tell that it is boolean. Says if you have this piece of code:

bool arrayIsEmpty = array.length == 0;
if (arrayIsEmpty) { ... }

It is already easy to read so you won't need == true, even for the person or programmer with less sense of evaluation.

share

Programming conventions are not necessarily "right" or "wrong". They exist to give the program a familiar structure to those reading it, so that possible mistakes will stand out more clearly -- it is difficult to "see" a problem if everything is slightly wrong-looking to you.

The important thing is that conventions be clearly defined and agreed upon by all participants (even if the agreement is like "I agree to use this convention while I work here" :), otherwise it does more harm than good.

Of course, the particularly case of comparing a boolean to true is plain wrong and to be avoided at all costs. ;-)

share

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