Peter Ritchie's MVP Blog

I'm constantly tempted (and occasionally waiver) to use the bang, but several coworkers have slapped me and I tend to agree with them that == false is ultimately the better, more immediately obvious answer.

I prefer   if (GetTrueOrFalse() == false) only because it more distinct when skimming the code.

if (isNotTrue()) is what I find ideal, but otherwise == false just feels unnecessarily verbose. Why not == true, while we're at it?

I prefer using "!", why not to use... Who will not understand ?

I don't know what's the difference, but I think that at the end both will have the same performance, or not ?

I have traditionally used the "!" variant, but am shifting towards using "== false". The reason is simple, it's extremely easy to miss the "!", particularly if the function call or property name starts with an "I" as in "if (!IsRelevant())". It takes 2 secods to write the additional "== false". It may (or may not) take 2 days of debugging to realize that you missread the if statement. The trade-off is pretty obvious.

A space or two turns out to be remarkably helpful:

if (!ill) can be misread.

if ( ! ill ) is far harder to ignore.

if ( ill == false ) sort of implies to me that the writer doesn't really 'get' this 'logic thing'.

Finally, of course, the best argument not to use if ( ill == true ) is that BOOL values are often "zero or non-zero", rather than "false or true". Sometimes those naughty API writers come up with creative non-zero values that signify hidden meaning, and if you compare to true, you'll get an issue.

While we're at it, how about "if ( ill != true )" or "if ( ill != false )"?

As I've often said about the "continue" statement, if it's too complicated for your programmers to understand the basic language principles, you may need to get better programmers.

And if you're concerned about "if (!x)" being harder to read then "if (x==false)", consider the possibility that you may introduce a few "if (x=false)" errors. [Why I prefer to put the constant on the left - "if (false=x)" is a compile-time error.

Explaining code to programmers, though, is the job of good variable naming, and good commenting.

Since this is filed under C#, the arguments of BOOL do not apply. Boolean (aka bool) can only have two values, there is no zero/non-zero issue. Aside from when using P/Invoke.

There also no chance of introducing "if (x=false)" errors, because C# doesn't allow assignments inside conditional statements.

I don't think that one or the other is easier to read. But doing "if (true != x)" would be confusing.

When x is actually a bool?, then "if (true == x)" is valid, but "if (x)" is not valid.

I use !. If i don't use == true, why would I use == false. If someone doesn't understand what ! means than he should at least read one book for C#. I can agree that ! character is less readable as Not is, but that is C# style (very clean source with as less characters as posible).

I use !, but I know what Rubio is saying about sometimes missing the !. To stop that problem, I set my context highlighting to make operators Red. Also breaks up long object.subobject.subobject... references and generally makes a lot of the short form operators in C# a lot easier to read.

Having a standard is the more important thing so you know what to expect in the code, especially in large teams of programmers. Even more important is having tools setup to enforce the rules.

Our checkin policy automatically stops people using == true and == false here so it's never an issue. Experience has taught us that unless coding standards are able to be enforced automatically, you cannot rely on them and are therefore of no value.

Be different and use:

if (GetTrueOrFalse().Equals(false))