How should I write my if statements?

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?

*"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, Dec 15 '11 at 14:06
See http://programmers.stackexchange.com/questions/12807/make-a-big-deal-out-of-true and http://programmers.stackexchange.com/questions/119968/is-the-use-of-explicit-true-comparison-always-bad — ChrisF, Dec 15 '11 at 14:19
@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? — juan, 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

Heinzi · Accepted Answer · 2011-12-15T14:30:03.103

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.

DeadMG · Answer 2 · 2011-12-15T14:16:53.807

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.

_“You're violating DRY.”_ No, DRY applies to series of instructions you're writing (which can be functionalized), not expressive usage of the language itself. If this is non-DRY, then simply using languages like Java & C# that require you repeat `public` & `private` all over the place (instead of a single `public:` like C++) is always non-DRY. **Checking a boolean value against `true` or `false` is a language feature, thus it's fair game and DRY-irrelevant (but guilty of lack of brevity/syntactic-sugar).** — Slipp D. Thompson, Dec 30 '16 at 05:52

score 1 · Answer 3 · answered Dec 15 '11 at 14:13

1

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.

answered Dec 15 '11 at 14:13

Jon Purdy

20,437
7
63
95

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)` – juan 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 06:19
The issue with `if (!(notDone != false))` is that the boolean logic behind it is needlessly complex and can/should be simplified according to the rules of boolean logic— which are language-irrelevant. Additionally testing for `== true` is an intentional language feature that's boolean-logic-irrelevant. – Slipp D. Thompson Dec 30 '16 at 05:55
@SlippD.Thompson: I’m not sure what you mean by “intentional language feature”. My problem with it is that `== true` is the identity function specialised to Booleans, so it’s always pointless—either don’t write it, or use the generic identity function if you’re passing it to a higher-order function. – Jon Purdy Dec 31 '16 at 22:35
@JonPurdy Some languages (C, JavaScript) allow `int`s to be used as conditionals (e.g. `if (0) { … }`)— that's feature of the language and an intentional language design choice. Many do not for the sake of stricter type safety— a different design choice regarding the language features. Similarly, most languages (but not all) offer comparing a boolean value to a boolean literal to create a new boolean value, and accept boolean values as a valid predicate in a conditional— an intentional (albeit common) language feature design choice. Some do not. – Slipp D. Thompson Jan 25 '17 at 04:26
@JonPurdy Point is, from a language design standpoint, a `someVar:bool == true` is redundant syntax for `somevar:bool`, and `someVar:bool == false` is redundant syntax for `!(someVar:bool)`. But these syntaxes are offered for the sake of allowing programmers to make their intent clearer when desired _(e.g. `if (self.isValid)` reads nicely, but `if (self.state)` does not)_, for consistency with other primitive data types, and for consistency with formerly popular languages (namely C). – Slipp D. Thompson Jan 25 '17 at 04:32
Also, your example `if (!(notDone != false))` is not only redundant, it's unsimplified— it's makes as much sense as saying _“I defy you to tell me at a glance: what does `var n = 5 * (pow(-1, 5) * -1) / 1` mean?”_ What it means is that you need to employ boolean algebra and simplify your equation to the point of readability (but not necessarily to the point of minimal syntax). The answer to “why do `== true` & `== false` exist” that I keep hitting on here is “the same reason blank lines, compound statements, and type aliases exist— readability; communication of intent”. – Slipp D. Thompson Jan 25 '17 at 04:46

score 0 · Answer 4 · answered Dec 15 '11 at 14:10

0

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)

answered Dec 15 '11 at 14:10

Morons

14,674
4
37
73

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 – juan Dec 15 '11 at 14:20
So you are making an Exception for one Specific case?! – Morons Dec 15 '11 at 14:23

How should I write my if statements?

4 Answers4