How should I write my if statements? [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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)