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.

Possible Duplicate:
Make a big deal out of == true?

When I was a young padawan in the world of programming, a person I considered a mentor told me that if statements are more aesthetically pleasing if written in the following way:

if (condition == false) {
    doSomething()
}

or

if (condition == true) {
    doSomething()
}

I personally found that in the first case it's true, or at least it's easier to read than

if (!condition) {
    doSomething()
}

In the "true" case, it's probably an overkill.
So I just use it when I want to test the condition for the "false" case.

Almost all my current coworkers tell me that way is plain wrong.

Does writing the if statements like that have a performance problem? Am I wasting milliseconds on each evaluation by doing it like that?
Sonar reports them as too complex

Can you convince me to not do it anymore? ...or that it's ok to do it like that?

share|improve this question

marked as duplicate by ChrisF Dec 15 '11 at 14:19

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
"Almost all my current coworkers tell me that way is plain wrong." - you mean which way? –  Péter Török Dec 15 '11 at 14:03
    
Almost all my current coworkers tell me that way is plain wrong And what's their reasoning? If there isn't none, or it's something vague like "performance", don't bother. Does writing the if statements like that have a performance problem? Nope. Can you convince me to not do it anymore? ...or that it's ok to do it like that? For such minor things, it doesn't really matter. If your team has a code conventions document, follow it. But that's not because there is a problem either way... Sonar reports them as too complex Deal with everything else first... –  Yannis Rizos Dec 15 '11 at 14:06
    
    
@ChrisF, I'm more interested in the == false case, which I don't think those questions address. Should I make it more explicit in the question? –  jmfsg Dec 15 '11 at 14:26
    
Yes. In general you need to make it clear why your's isn't a duplicate. However, I'm not sure the arguments for == false are any different to those for == true. –  ChrisF Dec 15 '11 at 14:29

4 Answers 4

up vote 5 down vote accepted

Use whatever is more readable.

In our company, it's customary to choose

if (isReportOpen()) {
    doSomething();
}

but

if (int.TryParse(a, b) == true) {
    doSomething();
}

In the first case, it's obvious that the method call isReportOpen() is used as a Boolean condition, so I'll use it as it is. It also reads fluently: if [the] report is open, [then] do something.

In the second case, it's not at all obvious that the method returns a Boolean indicating success or failure. Thus, it reads: if trying to parse a as an integer returned true, [then] do something.

share|improve this answer
if (condition == true) {
    doSomething();
}

This is just wrong. You're violating DRY. You want to know if it's true, then you check it again in the if. Anyone who can't grasp the == true of the if statement needs to go back to school. The same is true of the other example.

For this reason, they're also more difficult to read. When I read statements like that, I lose trust in the coder who wrote it and add it to a list of potential bugs. Doesn't he understand the concept of if? Is it a mistake for the condition to be that way? Do I need to stop and understand this whole function to try and grasp whether or not that is actually correct? What else is lurking here?

Also, in some languages, this is a bug in as of itself. Imagine, in C++11,

std::unique_ptr<int> i;
if (i) // valid

if (i == true) // not valid

In C++11, the language statements which expect boolean expressions are an explicit conversion to bool, which can invoke the ones used in e.g. smart pointers, but your comparison to true won't. Fortunately, the compiler will spank you for it, but it's still a bug.

There's no need at all to invoke boolean constants in such statements.

share|improve this answer
1  
What about the other case? Using == false instead of !? –  jmfsg Dec 15 '11 at 14:21
    
@JuanManuel: Equally bad. –  DeadMG Dec 15 '11 at 14:47

By using ==, you’re subverting the meaning of if: if the condition is true, carry on; if it’s false, do the else case, if any. if (x == true) says “if it is true that x is true”, and if (x == false) says “if it is true that x is false”. This is not only redundant, but quickly becomes misleading.

I defy you to tell me at a glance: what does if (!(notDone != false)) mean? “If it is not true that notDone is not false”? Why say something so convoluted when if (!done) (“if not done”) suffices?

Simplify, simplify.

share|improve this answer
    
Well, using your example it'd be if (done == false) (if it's not true that it's done), which I find more readable than if (!done) –  jmfsg Dec 15 '11 at 14:23
    
@JuanManuel: I was just offering an example of how quickly code becomes inscrutable when bad names meet bad style. Oh, and I read if (done == false) as “if it’s true that done is false”, so it’s no wonder that I prefer the other. In part it depends on your understanding of the code, but I prefer straightforwardness and concision wherever possible. –  Jon Purdy Dec 16 '11 at 6:19

Performance problem? No.

I personally prefer

if (!condition) 

And

  if (condition)

I like my If statements to ALWAYS resolve to true.

For example I would never to something like this: (I don't even know if this is valid syntax) (Looks very complex Doesn't it?)

if ((a==b)==False) 

I Would do:

 if (!(a==b)) 

or likely

 if (a<>b)
share|improve this answer
1  
In that case I'd do if (a != b), I was talking more about conditions that don't have the equality operator in them... like evaluating variables –  jmfsg Dec 15 '11 at 14:20
    
So you are making an Exception for one Specific case?! –  Morons Dec 15 '11 at 14:23

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