Confusing If Statement?

Question

I always use If statement (In C#) as (1. Alternative);

if (IsSuccessed == true)
{
   //
}

I know that there is no need to write \"== true\"

Answer 1

I prefer the second alternative. I think it's more readable, but the first alternative has the advantage of staying the same if you need to use Boolean? for some reason.

Answer 2

The two expressions are equivalent in C#, but be aware than in other languages they are not.

For example, in C++, the first option accepts only a boolean value with a value of true. Any other value on IsSuccessed will invalidate the condition.

The second option accepts any value that is "truthy": values like 1, or any non-zero, are also considered valid for the if.

So these conditions will validate:

// Truthy validation (second option)
if(1) {...} //validates
if(2) {...} //validates

While these others will not:

// Equals to true validation (first option)
if(1==true) {...} // does not validate
if(2==true) {...} // does not validate

Again, this doesn't apply to C#, since it only accepts booleans on ifs. But keep in mind that other languages accept more than just booleans there.

Answer 3

I claim that someone favouring the first alternative has a sketchy grasp of boolean logic. They might “understand” it intellectually, but they certainly don’t grok it; they haven’t internalized this way of thinking.

After all, does anyone every use the following idiom? “If it’s raining tomorrow is false we may go swimming” – NO, of course not. nobody says something like this, it’s ridiculous. What argument supports the claim that this idiom suddenly becomes clear when applied in a programming (as opposed to natural) language?

Answer 4

i use the first when i started programming but kinda get used to the second option. It also saves time type extra letters.

Answer 5

I don't like the first option. Not only is it redundant, but a simple typo will introduce a bug.

Consider this

bool b = false;

if (b = true) {
   Console.WriteLine("true");
}

Obviously the code will output "true" but that was probably not the intention of the programmer.

Fortunately tools like Resharper warns against this, but it compiles with the default settings (*).

Using the bool directly will remove the issue entirely.

(*) To be fair, VS also warns against this and if you turn on Warnings as errors it won't even compile.

Answer 6

If the name of the boolean value makes it perfectly clear what it is, then I'd always opt for version 2. However, sometimes you're stuck with a particularly obtuse variable name that you can't change, at least, can't change right now... Refactoring is all well and good, but I try and avoid refactoring too heavily when making functional changes to the code as well.

For example:

if (!NoDropDownInHeader == true)
{
  // Activates when there *is* a dropdown in the header)
}

I've actually seen this particular example in production code and simplified it down to:

if (NoDropDownInHeader == false)
{
 // Activates when there *is* a dropdown in the header
}

And I personally think that both examples are more readable (although arguably the first example may be on par with this one for difficulty of mental parsing) than:

if (!NoDropDownInHeader)
{
 // Activates when there *is* a dropdown in the header
}

Note: Yes, I know the variable is badly named, but changing it in the multitude of places that it was present was outside the scope of the change I was making due to the number of places if would affect.