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


if (condition == true) {

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

if (!condition) {

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
  • @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

Use whatever is more readable.

In our company, it's customary to choose

if (isReportOpen()) {


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

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.

if (condition == true) {

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.

  • 1
    What about the other case? Using == false instead of !? – juan Dec 15 '11 at 14:21
  • @JuanManuel: Equally bad. – DeadMG Dec 15 '11 at 14:47
  • “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 5:52

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.

  • 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 6: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 5: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 ints 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 4:26

Performance problem? No.

I personally prefer

if (!condition) 


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

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