Literature on boolean naming/usage conventions?

[Andre Anneck]

Hi there,

lately I have been involved in a discussion that ended unsatisfactory
from my point of view... I couldn't argue against: "Common literature
discusses the same problem and the majority of the resources come to
the conclusion that the "==" comparator should be avoided if you
compare with a boolean."

Example:

if ( on ) <--// Supposedly literatur say's so.

if ( on == true ) <--// Supposedly literatur say's NOT to use this.

As you can see this drills down to readablity and maintainability.

My Problem is that IMHO having the "==" in place makes code more
readable and robust against change-bugs. Sadly the other guy is in
charge, but could'nt name any books to enlighten me :-/.

Now since I would like to understand his argument before I decompile
it ...

Can anyone of you point me to literature reference that discuss this
topic AND give out the rule-of-thumb to avoid using "==" with
booleans?


Take care,

André

P.S.:
And yes, it's only about Java not C/C++/*any* Naming-Conventions.

 

[Andrew Thompson]

if ( on ) <--// Supposedly literatur say's so.

Stuff literature, use common sense.

if ( on == true ) <--// Supposedly literatur say's NOT to use this.

So, for the opposite, you could write..

if ( on != true )
if ( on == false )
if ( on == !true ) ..or
if ( !on == true )

...depending upon the time of day
and your own inclination.

As you can see this drills down to readablity and maintainability.

Indeed! And since the first is both
more maintainable (shorter) and easier to
read, it makes perfect sense to use it.

[ The literature was right. ]

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane

 

[Michael Borgwardt]

if ( on ) <--// Supposedly literatur say's so.
if ( on == true ) <--// Supposedly literatur say's NOT to use this.

Dunno about literature, but the second is *definitely* considered bad
style by anyone I've ever seen discussing the topic. Usually, it
comes up as a typical example of newbie code, written by people
who don't understand how expressions are evaluated, or what expressions
are. Often, it's even compunded to:

if( condition = true)
{
return true;
}
else
{
return false;
}

As you can see this drills down to readablity and maintainability.

My Problem is that IMHO having the "==" in place makes code more
readable and robust against change-bugs.

How so? It's completely redundant. And the clarity should be offered by
well-chosen names, not redundant code. Anything expressed by "==true"
can be just as well (or better) expressed by giving the variable a
meaningful name, one that makes the sequence "if (<condition>) doStuff();"
read like an English sentence. Often this can easily be done by
including "is" or "has" in the name.

 

[Michael Borgwardt]

if( condition = true)

Of course that should be "==". And provides yet another reason why
it should be avoided bad: without the comparison, this common typo
and the bugs it causes cannot occur.

 

[Andrew Thompson]

Michael Borgwardt wrote:

Of course that should be "==".

LOL.. I thought that *was* your point!
(And a good one at that)

Now I'll have to go back and reread it,
armed with my new understanding that '='
was simply a typo. ;-)

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane

 

[Jacob]

if ( on ) <--// Supposedly literatur say's so.
if ( on == true ) <--// Supposedly literatur say's NOT to use this.

Normally the problem you see with readability vanish
if if you name the variable properly. In most cases
this includes prepending some carefully chosen name
with "is".

Example:

if (status) // unreadable, I agree

if (status == true) // marginally better perhaps

if (isDone) // order of magnitude better

 

[Juha Laiho]

(e-mail address removed) (Andre Anneck) said:

lately I have been involved in a discussion that ended unsatisfactory
from my point of view... I couldn't argue against: "Common literature
discusses the same problem and the majority of the resources come to
the conclusion that the "==" comparator should be avoided if you
compare with a boolean." ....
Can anyone of you point me to literature reference that discuss this
topic AND give out the rule-of-thumb to avoid using "==" with
booleans? ....
And yes, it's only about Java not C/C++/*any* Naming-Conventions.

Actually the boolean comparision issue is somewhat bound with
naming convention issue (as was demonstrated here, using booleans
without comparision operation is readable only when the boolean
is properly named), but is not that much language-dependent;
the same rule works with C, C++, Java, Perl.. .

As for literature references, this is briefly mentioned in
'The Practice of Programming' by Kernighan&Pike, p.4 (in the
context of naming functions). I think the same book contains
also more on this topic, but couldn't find at the moment.

 

[Chiron Paixos]

Normally the problem you see with readability vanish
if if you name the variable properly. In most cases
this includes prepending some carefully chosen name
with "is".

100% ACK

Example:

if (status) // unreadable, I agree

if (status == true) // marginally better perhaps

I prefer
if (true == status)
as this way you can't accidently use '=' without getting a compilation
error

 

[Joona I Palaste]

Stuff literature, use common sense.

So, for the opposite, you could write..

if ( on != true )
if ( on == false )
if ( on == !true ) ..or
if ( !on == true )

..depending upon the time of day
and your own inclination.

Or even...

if (!on != !false)

 

[Joona I Palaste]

Or even...

if (!on != !false)

Erm, sorry, logic error there. I meant:

if (!on != false) or
if (!on != !true)

 

[andreas]

if ( on != true )
i actually had to deal with someones code, which used:
if(notTrue == false)

what is it now. true? false? what is true or false?
i really didn't feel like twisting my mind everytime i see
something like this.
muchbetter for example:

if(buttonPressed)

THIS makes it readable...


andreas

 

[Alex Hunsley]

Of course that should be "==". And provides yet another reason why
it should be avoided bad: without the comparison, this common typo
and the bugs it causes cannot occur.

One could maybe say that an accidental deletion could turn:

if (!buttonPressed) {

into

if (buttonPressed) {

without you noticing. Ok, maybe not as common as = vs == error....
Doesn't the compiler complain if you write

if (javaSquished = true)

anyway?

 

[Michael Borgwardt]

Doesn't the compiler complain if you write

if (javaSquished = true)

anyway?

Nope. Perfectly valid boolean expression.