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

[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

[John Puopolo]

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
"Alfred Taylor" <om***@R-E-M-O-V-Eyahoo.com> wrote in message
news:Ou******** ******@tk2msftn gp13.phx.gbl...

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

[Bruce Wood]

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

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.

[Daniel Pratt]

Hi Alfred,

"Alfred Taylor" <om***@R-E-M-O-V-Eyahoo.com> wrote in message
news:Ou******** ******@tk2msftn gp13.phx.gbl...

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.

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

[Bruce Wood]

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 (isADuplexPrint Job)

much more readable than this:

if (isADuplexPrint Job == 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]

Oooh! Good one!

[Alfred Taylor]

"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** **************@ c13g2000cwb.goo glegroups.com.. .

From personal experience, I can say that reading

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.

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

[Alfred Taylor]

Thanks Daniel. That is definitely a very legitimate reason for avoiding "==
true" and "== false".

-A

"Daniel Pratt" <ko************ ******@hotmail. com> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

Hi Alfred,

"Alfred Taylor" <om***@R-E-M-O-V-Eyahoo.com> wrote in message
news:Ou******** ******@tk2msftn gp13.phx.gbl...

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.

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

[carl.manaster]

Hi, Alfred,

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

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

if ( boolVar == true ) instead of if ( (boolVar == true) == true)
Peace,
--Carl

[Olorin]

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==t rue) {...}
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==t rue).

F.O.R.