Coding Standards, why if ( boolVar ) over if ( boolVar == true )

  • Thread starter Thread starter Alfred Taylor
  • Start date Start date
A

Alfred Taylor

I've been flipping through various coding standards documents for C#/.NET
and all of them say to use:

if ( boolVar ) {...} instead of if ( boolVar == true ) {...}

For the life of my I can't figure out why. If anything, I would guess the
opposite would be better to use since the ! operator is so hard to read.

Upon quick glance,

if ( boolVar == false ) is easier to understand than if ( !boolVar )

Anybody have some more concrete reasons why one is preferred over the other
aside from one being less typing.

Thanks,
-A
 
Alfred:

This can degenerate into a holy war. In general, I would recommend keeping
it as simple as possible. Think about looking at this code 3 months from
now, at 2:00 AM under a deadline after working 15 hour days for 2 months
straight.

8-)... Been there...

John
 
This is where I invoke my #1 rule of programming style. :)

"Code written to a mediocre standard is better than brilliant code that
is not standard."

or, stated another way:

"If everyone else is doing it a standard way, your clever solution is
by definition no longer clever, unless it offers some stunning
advantage over the standard."

If everyone in the industry were writing

If (boolVar == true)

and I were to write instead

if (boolVar)

claiming that it was "better" because I had to type fewer characters, I
would not blame my colleagues if they were to give me the wedgie to end
all wedgies and tossed me out on the street. Every time they were to
read my code they would have to mentally stop and think about what I
was doing.

The reverse is also true.

Almost every C / C++ / Java / C# programmer out there writes

if (boolVar)

and

if (!boolVar)

that fact, in and of itself, makes the alternative syntax "less
readable".
From personal experience, I can say that reading
Click to expand...

if (boolVar == false)

is like a speed bump for me. I've been reading C for 20 years and I'm
used to the standard. It has, in effect, become "more readable" for me.
 
Hi Alfred,

Alfred Taylor said:
I've been flipping through various coding standards documents for C#/.NET
and all of them say to use:

if ( boolVar ) {...} instead of if ( boolVar == true ) {...}

For the life of my I can't figure out why. If anything, I would guess the
opposite would be better to use since the ! operator is so hard to read.

Upon quick glance,

if ( boolVar == false ) is easier to understand than if ( !boolVar )

Anybody have some more concrete reasons why one is preferred over the other
aside from one being less typing.
Click to expand...

In short, it prevents syntax errors from becoming logical errors. It's
not unusual, especially for people who haven't used C-variant languages in
the past, to accidentally use the assignment operator (=) instead of the
equality operator (==). Consider this C# code:

int i = 0;
...
if (i = 3) {...}

The above code would be flagged as a compile-time error because the
assignment operator (=) returns the value assigned, which in this case is 3,
which is not a boolean value. On the other hand, if you do this:

bool boolVar = false;
...
if (boolVar = true) {...}

The above code will not cause a compile time error, even though it's
probably not what was intended. The assignment operator (=) returns the
value assigned, which in this case is true, which *is* a boolean value.

If you never use "== true" or "== false" the mistake can be avoided.

Regards,
Daniel
 
For those who found my preceding reply utterly unconvincing :) I offer
the following:

The problem with Alfred's original sample was the name of the variable.

Programmers are _supposed_ to name their boolean variables to express
the condition that they represent. In that situation, I find this:

if (isADuplexPrintJob)

much more readable than this:

if (isADuplexPrintJob == true)

because in the first example I'm expressing something in terms of my
problem domain ("if this is a duplex print job then I want to...")
whereas in the second example I have to remember that this is a boolean
variable, and that it's either true or false, and that "true" means
that it is a duplex print job.

One encourages me to think about my problem; the other notation
encourages me to think about what's going on inside the machine.

Of course, if you name your boolean variable "flag", or something
equally opaque, then this argument doesn't hold water. But then, we
would never do _that_, would we...? :)
 
Bruce Wood said:
if (boolVar == false)

is like a speed bump for me. I've been reading C for 20 years and I'm
used to the standard. It has, in effect, become "more readable" for me.
Click to expand...

That's a good point. I know the times I've run across that style of code,
I've had to pause momentarily to "recompose" myself. ;)
-A
 
Thanks Daniel. That is definitely a very legitimate reason for avoiding "==
true" and "== false".

-A
 
Hi, Alfred,
if ( boolVar ) {...} instead of if ( boolVar == true ) {...}
Click to expand...

Because it's redundant. One might as well ask, why

if ( boolVar == true ) instead of if ( (boolVar == true) == true)
Peace,
--Carl
 
100% correct.

Also, as I was reading this thread, I kept on thinking that in

if(something) {...}
you are looking at the value of 'something', whereas in

if(something==true) {...}
you are technically speaking looking at the result of a comparison
between 'something' and a value ('true'). Granted the net effect is the
same, but, technically speaking, there are differences. And if
something was not a boolean, the comparison might actually open a whole
can of worms (but that would be a different playground, right?).

Still, the reason illustrated by Daniel above is probably the best
reason to avoid if(something==true).

F.O.R.
 
Bruce Wood said:
For those who found my preceding reply utterly unconvincing :) I offer
the following:

The problem with Alfred's original sample was the name of the variable.
Click to expand...

Fair enough. ;)

-A
 
Incidentally (although I'm sure that this _will_ cause a holy war), I
apply the same reasoning to curly braces and all other manner of code
formatting: if I start work at a shop that formats their code a certain
way, and I insist upon continuing to do it "my way" because my way is
"better," then I am an idiot.

It doesn't matter how stupid "their way" of formatting code looks to
me. If everyone else in the shop is used to that, then that is what is
"more readable" and it is what I should be doing, too.

My dream shop would have an automated code formatter that would just
mash everyone's code and make it look the same every time it was
checked into the library. Visual Studio's "Edit->Advanced->Format
Selection" operation is your friend! Productivity wouldn't jump, but it
would improve.

I read stories of programmers (during the big boom, when we could get
away with anything, including bringing pets to work) insisting on
writing formatters / deformatters so that they could transform others'
code into "their" style, code in "their" style, and then transform the
code back to the group standards. I just shake my head in wonder at
such nonsense.
 
As a quick comment. I have a pet hate against this minimal typing when
it comes to string comparisons. Does anybody actually find this
readable ?!:

if ( !strcmp( string1, string2 ) )
{
// Strings match
}
else
{
// Strings dont match
}


I've gotten into the habit of putting the fixed value on the
left-hand-side. It takes a bit of getting used to, but as a consistent
approach I use this across the board, regardless of type.

if ( true == bValue )
{
}

if ( 0 == strcmp( string1, string2 ) )
{

}


etc..
etc..


Rich
 
I've gotten into the habit of putting the fixed value on the
left-hand-side. It takes a bit of getting used to, but as a consistent
approach I use this across the board, regardless of type.
Click to expand...

Argh, I absolutely hate that. Mathematical tradition always puts
variables on the left and constants on the right of a comparison, and
that's also the natural way to read a comparison. One of the best
things about C# as compared to C++ is that there's no auto-conversion
of everything to boolean, so you no longer have to invert comparisons
to prevent typo bugs...
 
As a quick comment. I have a pet hate against this minimal typing when
it comes to string comparisons. Does anybody actually find this
readable ?!:

if ( !strcmp( string1, string2 ) )
{
// Strings match
}
else
{
// Strings dont match
}
Click to expand...

This is a different issue altogether. strcmp does not actually return
boolean value. So, although the above will still work, it is
technically incorrect because the other possible return values are
negative or positive numbers denoting which string is "greater"
alphabetically, rather than true or false.

Above should have been
if(strcmp(str1,str2)==0)
//stings match
I've gotten into the habit of putting the fixed value on the
left-hand-side. It takes a bit of getting used to, but as a consistent
approach I use this across the board, regardless of type.

if ( true == bValue )
Click to expand...

This is uncessessary extra bit of coding imo. Good C/Java/C#
programmers should be able to read

if(bValue)

happily and not dismiss the ! operand as "hard to read" e.g.

if(!bValue).

Daniel has already given a very good example as to why using

if(bvalue==true)

is a not a good practice and

if(true==bValue)

is just a workaround, imo, for those not confident enough to read pure
C/Java/etc syntax.

Just my 2p worth.

Cheers,

Paul.
 
int i = 0;
...
if (i = 3) {...}
Click to expand...

In good old days of C and C++ this would not have been flagged as a compile
time error which got quite a few people into habit of writing the condition
with constant on the left had side like : if ( 3 == i) This would trap the
missed equal to sign (if (3 = i)) as a compiler error !!
 
I never liked the

if (!strcmp(string1, string2))

convention in C. It just struck me as sloppy: strcmp returns a
tri-state value, not a dual-state value, so using ! always struck me as
a cheap trick. I always preferred to code

if (strcmp(string1, string2) == 0)

in order to highlight the fact that it could be zero, less than zero,
or greater than zero. As GingerDeafMan points out, thanks to Anders
Hejlsberg and team, C# doesn't allow you to treat integers as booleans,
so now everyone has to do it my way. :)

Of course, those few times when I was in a shop that had standardized
on testing strcmp results using the ! operator, I had to hold my nose
and adapt.... :)
 
Back
Top