question to Roedy and others about boolean testing

J

Jean Lutrin

Hi,

Roedy, in another thread, you said that I should not write :

if (someBoolean == true) {...}

but simply :

if (someBoolean)

when working with a boolean primitive.


However I do find :

if (!someBoolean) {...}

to be much less readable than :

if (someBoolean == false) {...}

(and this is especially true, at least for me,
when the boolean has a lloonngg name, like :
isMD5ChecksumAvailable... it is easy
to forgot about the "!" or simply not to see
it, not that I advice using long names btw ;)

And I know that there are others who prefer to
use the latter when doing such tests.

So my 2 Eurocents question is : would it make
sense in source code to use :

if (someBoolean) {...}

when testing for "true" and :

if (someBoolean == false)

when testing for false ?

I have to say we have strong guidelines here
at work (and I mainly established them, back in
the days, then refined them based on advices
given in the chapter in "Bitter Java"
devoted to this subject) and I would like to
know what is the "best" way to do it...

If I'm really motivated I could hack a little
grep/sed/whatever Unix script on the CVS server
we now all use (that I set up some weeks ago)
to see what the developers favor and if they
are consistent.

Statistics on this topic anybody ? Or guidelines ?

Cya later and, as usual, excuse my french ;)

Jean




P.S : sometimes it is even clearer, at least
for me when I read it, to write :

if (... != true) {...}

instead of :

if (... == false) {...}

It all depends on the circumstances. Btw, it is
not "just about logic", I think that the fact
that my mother tongue is french means I "read"
the "english" code differently than an native
english speaker... So what may sounds redundant
for you may just seem "natural" for me. Of
course, I think that consistency is the most
important thing and that everybody should do
the same, because it facilitates team work
(then again my team is all french-speaking but
we don't use a single french comment nor a
single french class/variable/file names :
our naming convention is ASCII compliant :)
 
R

Roedy Green

if (!someBoolean) {...}

If you write that as

if ( ! someBoolean ) { ... }

I think you would find you would not miss the !

How do you talk to yourself when you read code:

if ( ! ready )

I would read as "if not ready"

if ( ready == false )

I would read as "if ready is false"

I find the first more natural.
 
D

DigiAl

Jean Lutrin said:
Hi,

Roedy, in another thread, you said that I should not write :

if (someBoolean == true) {...}

but simply :

if (someBoolean)

when working with a boolean primitive.


However I do find :

if (!someBoolean) {...}

to be much less readable than :

if (someBoolean == false) {...}
<snip>


Surely its whatever you prefer, I understand that its good to be consistent
but for something like this don't worry about the 'guidelines' but worry
about how easy it would be for you to debug your code in the future.

Well that's my 2 pence anyway :)

alan.
 
C

Chris Uppal

Jean said:
However I do find :

if (!someBoolean) {...}

to be much less readable than :

if (someBoolean == false) {...}

I'll admit that if I saw:

if (someBoolean == false)

in some code, then I wouldn't automatically assume that the author was an idiot
in the way that I would for:

if (someBoolean == true)

but I'd still advise against it.


One reason is that it leads to a "discontinuity" between how you write the code
when you are testing for the condition being true and how you write it when the
condition is false. E.g. I would call the following unacceptably ugly:

if (someCondition)
{
// code
}
else if (someOtherCondition == false)
{
// more code


The other reason is that you do, and will, have to read code that doesn't use
that convention. You've said that you find it relatively difficult to "see"
the "!", but what that suggests to me is that you need more practise in
reading code that uses "!", not a systematic attempt to pretend that the
construction doesn't exist. If you could change the definition of the Java
language, or at least get enough support from the Java community that
"condition == false" was the de-facto standard expression, then all well and
good. But you can't, so I think you'd be better off learning to be comfortable
with Java as it is commonly written.

-- chris
 
M

Marco Schmidt

Jean Lutrin:

[...]
However I do find :

if (!someBoolean) {...}

to be much less readable than :

if (someBoolean == false) {...}

I think once you'll have more Java experience using !b instead of b ==
false will become very natural. It's just a matter of time.

Besides, almost everybody else is "doing it". That usually isn't
really the best reason to do things, but whenever other people read
your code or you read other people's code, there will be some
confusion because you do it differently. Not much confusion, but the
more you digress from Sun's coding standards, the more time it will
take the average developer to understand your code.

There are other typical code lines you should get used to. Including:

while ((i = in.read()) != -1) { ... }

int j = a > 12 ? 4 : 3;

....

There are more verbose and beginner-friendly ("readable") ways of
expressing these lines, but they are standard and avoiding them may be
more of a problem than improvement.

Regards,
Marco
 
R

Roedy Green

Surely its whatever you prefer, I understand that its good to be consistent
but for something like this don't worry about the 'guidelines' but worry
about how easy it would be for you to debug your code in the future.

You have to be consistent, especially on a team. In general, when
someone shows me a shorter way to express something, that usually does
it for me. Shorter is better.

My eyes have enough to take in each day without meaningless
decoration.
 
T

Tim Van Wassenhove

However I do find :

if (!someBoolean) {...}

to be much less readable than :

if (someBoolean == false) {...}

With if (someBoolean == false) you also run the risk of typing
if (someBoolean = false).

PS:
Most books advice to write a comparison of a variable with a constant as
if (constant comparator variable)
 
L

Lasse Reichstein Nielsen

Tim Van Wassenhove said:
PS:
Most books advice to write a comparison of a variable with a constant as
if (constant comparator variable)

Well, I find that hard to read :)
I haven't read that suggestion. What is the basis for it?

/L
 
M

Marco Schmidt

Tim Van Wassenhove:
With if (someBoolean == false) you also run the risk of typing
if (someBoolean = false).

But different from C, the Java compiler will complain about that
because it's not allowed.

[...]

Regards,
Marco
 
M

Mark Thornton

Marco said:
Tim Van Wassenhove:




But different from C, the Java compiler will complain about that
because it's not allowed.

Oh yes it is. Java allows this construct only for boolean types, whereas
C permits it for other types as well.

Mark Thornton
 
J

Joona I Palaste

Oh yes it is. Java allows this construct only for boolean types, whereas
C permits it for other types as well.

In fact, C permits it for any type that either is a scalar type (i.e.
a number of a pointer) or "decays" into a scalar type when used as a
value.
 
J

Joona I Palaste

Joona I Palaste said:
In fact, C permits it for any type that either is a scalar type (i.e.
a number of a pointer) or "decays" into a scalar type when used as a
value.

Confusing typo - I meant a number *or* a pointer.
 
M

Marco Schmidt

Joona I Palaste:
Yes it is. Just try it.

Indeed. Why, oh why? I thought that was one of the things they removed
because it was such an obvious source of errors? At least in Java you
can't do the assignment with ints anymore, but that has more to do
with the fact that there is a strict separation between int and
boolean.

Regards,
Marco
 
J

Joona I Palaste

Marco Schmidt said:
Joona I Palaste:
Indeed. Why, oh why? I thought that was one of the things they removed
because it was such an obvious source of errors? At least in Java you
can't do the assignment with ints anymore, but that has more to do
with the fact that there is a strict separation between int and
boolean.

I feel the opposite way. If there are easily defined semantics for
something, and allowing it doesn't cause any extra work (on the
contrary, *not* allowing it would cause extra work) then I see no
harm in allowing it.
For example, code after an unconditional return, catching exceptions
that are never thrown, empty statements, etc. Java goes out of its
way to self-righteously disallow them. I bet JVM implementors actually
have to insert "special case" code just to disallow those things.
Now, using a variable that might not have been initialised, *THAT*
should well and good be disallowed. It makes the program work more
deterministically.
 
M

Marco Schmidt

Joona I Palaste:
I feel the opposite way. If there are easily defined semantics for
something, and allowing it doesn't cause any extra work (on the
contrary, *not* allowing it would cause extra work) then I see no
harm in allowing it.

Some constructs make it easier to introduce errors than others.
Obviously is quite subjective what is readable and what not, so there
probably won't be a definite answer.

BTW, just now somebody in the German Java newsgroup sent some code
asking why it wouldn't work. It includes lines like:

if (state1 =true &&Integer.parseInt(evt.getActionCommand())==5){

So that particular Java feature does confuse people. Just an example,
not a proof, of course.
For example, code after an unconditional return, catching exceptions
that are never thrown, empty statements, etc. Java goes out of its
way to self-righteously disallow them.

You want more freedom, but in these special cases I'm not sure what
you gain. On the other hand, lots of beginners will probably get more
insight. Maybe a warning instead of an error would be a nice
compromise.

Regards,
Marco
 
J

Joona I Palaste

Marco Schmidt said:
Joona I Palaste:
Some constructs make it easier to introduce errors than others.
Obviously is quite subjective what is readable and what not, so there
probably won't be a definite answer.
BTW, just now somebody in the German Java newsgroup sent some code
asking why it wouldn't work. It includes lines like:
if (state1 =true &&Integer.parseInt(evt.getActionCommand())==5){
So that particular Java feature does confuse people. Just an example,
not a proof, of course.
You want more freedom, but in these special cases I'm not sure what
you gain. On the other hand, lots of beginners will probably get more
insight. Maybe a warning instead of an error would be a nice
compromise.

Yes, I'll settle for warnings, insults, even threats, as long as the
compiler obediently compiles my code into the correct bytecode.
 
T

Tim Van Wassenhove

Well, I find that hard to read :)
I haven't read that suggestion. What is the basis for it?

I don't like it either.

But, if you try to compile it, the compiler will notice that you are
trying to assign a value to a constant and complain about that.
 
J

Jean Lutrin

Lasse Reichstein Nielsen said:
Well, I find that hard to read :)
I haven't read that suggestion. What is the basis for it?

Hi,

I think I can answer that one...

First, in this very special case, when writing :

if (false == someBooleanVariable) {...}

you don't risk writing inadvertently :

if (false = someBooleanVariable) {...}

The compiler would catch is as soon as possible (actually
my IDE catch it instantly).

While if you write :

if (someBooleanVariable = false) {...}

it is generally a mistake and would go more or less
unnoticed.

Now, having that said, any decent IDE *will*
help spot such obvious errors (it may be "correct", but
very often it is a mistake... If I do this inadvertently,
IntelliJ, for example, warns me that I made an unnecessary
assignation to someBooleanVariable somewhere else in my
code. That is just one example).

Secondly, imagine, for "very large value of 'constant',
'comparator' and 'variable'" ;) (this may not be exactly
what Tim had in mind, but it certainly is also true -- I
think there's a section of "Effective Java" that
explain this), you have this :


static final String SOME_PROLIFIC_POSTER = "Roedy";

String mostFrequentPoster;

if ( mostFrequentPoster.equals(SOME_PROLIFIC_POSTER)) {...}

If "mostFrequentPoster" is null, you have a null pointer exception
(which may, or may not, be a problem).

While :

if (SOME_PROLIFIC_POSTER.equals(mostFrequentPoster)) {...}

will have the correct behaviour if mostFrequentPoster is null...

Cya all,

Jean
 
C

Chris Smith

Chris said:
I'll admit that if I saw:

if (someBoolean == false)

in some code, then I wouldn't automatically assume that the author was an idiot
in the way that I would for:

if (someBoolean == true)

This got me curious, so I did a search through a current project from
work to find all occurrences of "== true". I found seven. Six of those
came from a contractor we had working for us who had a very verbose and
tedious coding style, but he wasn't really an idiot. The other one I
wrote. It is:

if (model.getTrueFalseCorrectAnswer() == true)
{
trueButton.setSelected(true);
}

It's written that way because it reads better. "true" is a possible
correct answer for the question. The boolean expression doesn't
represent a condition that's either true or false. I wonder if you
object to that.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top