You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeff Turner <je...@apache.org> on 2003/03/07 15:16:24 UTC
Coding style question: backwards null checks
Hi,
Quick question. Why do people put null checks backwards:
if ( null != this.inputSource ) {
IMHO it is harder to read than
if ( this.inputSource != null ) {
and means exactly the same thing.
I think this is a throwback from the days of C, where swapping the
conditions was a handy way to avoid =/== bugs like:
if ( this.inputSource = null ) {
But in Java, the compiler catches this error:
Found 1 semantic error compiling "Test.java":
10. if (inputSource = null) {
<---------------->
*** Error: The type of this expression, "Source", is not boolean.
So is there any other reason for this? Can I do a massive grep for
'null !=' and change these?
--Jeff
Re: Coding style question: backwards null checks
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Good point. I was asked myself why they used this construction. Nice answer.
I think it can be changed too.
Antonio Gallardo
> Hi,
>
> Quick question. Why do people put null checks backwards:
>
> if ( null != this.inputSource ) {
>
> IMHO it is harder to read than
>
> if ( this.inputSource != null ) {
>
> and means exactly the same thing.
>
>
> I think this is a throwback from the days of C, where swapping the
> conditions was a handy way to avoid =/== bugs like:
>
> if ( this.inputSource = null ) {
>
> But in Java, the compiler catches this error:
>
> Found 1 semantic error compiling "Test.java":
>
> 10. if (inputSource = null) {
> <---------------->
> *** Error: The type of this expression, "Source", is not boolean.
>
>
> So is there any other reason for this? Can I do a massive grep for
> 'null !=' and change these?
>
>
> --Jeff
Re: Coding style question: backwards null checks
Posted by Johan Sjöberg <jo...@avaintec.com>.
Berin Loritsch wrote:
> Jeff Turner wrote:
>> So is there any other reason for this? Can I do a massive grep for
>> 'null !=' and change these?
>
>
> No, I think that is the major reason.
I remember a discussion between Peter D. and someone here on the list
about this. I can't find it in the web archive so I include it from my
local history. It might not be interesting though.
<INCLUDED-MESSAGE>
At 08:24 1/12/00 -0500, you wrote:
>Just a stylistic nit-pick:
>
>I noticed you committed a change that does nothing
>but change the style of the code. Let me explain
>why I do it the way I do.
>
>regarding "if (null != message) ...":
>
>to me this is not semantically correct, it is kind
>of backwards. We are not checking if null is
>message, but if message is null. I also think that
>by keeping it "if (message != null) ..." it is more
>readable and understandable by most English speaking
>folks.
I used to agree .. thou apparently we are wrong ;) (Had an argument with
a professor over this one time ;] ) The reason basically comes down to
expectations. "if( XXX == ... )" where XXX is any immutable-constant
(like integer values, floats, nulls) is meant to facilitate
understanding. It helps you understand the difference between
"constants" and l-vars (or whatever they are called). Students who were
taught "if( XXX == ... )" gain a "deeper" understanding of programming
language. In some languages (namely c/c++) it also has added benefit of
using compiler to check you don't have single '=' etc - thou this is for
all purposes not relevent to java.
<SNIP/>
Cheers,
Pete
</INCLUDED-MESSAGE>
Perhaps there is something to that, but ( null == arg ) still twists my
head after some time spent on reading Avalon code ;)
Cheers,
//
Johan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Coding style question: backwards null checks
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Fri, Mar 07, 2003 at 12:44:04PM -0500, Tony Collen wrote:
>
> Likewise, I've seen something like this in code... can't remember if it's
> anywhere in Cocoon:
>
> if ( "something".equals(stringToCompare) {
> ...
> }
>
> IMO it seems more straightforward and easier to read if it's:
>
> if ( stringToCompare.equals("something") ) {
> ...
> }
>
> Is this just a matter of style as well? The first way seems goofy if you
> ask me.
It's style but also beneficial because:
if ("something".equals(stringToCompare)) { ... }
works even when 'stringToCompare' is null, where:
if (stringToCompare.equals("something")) { ... }
would throw an NPE. The first one saves a leading null check.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: [ot] Re: Coding style question: backwards null checks
Posted by Johan Sjöberg <jo...@avaintec.com>.
Leo Simons wrote:
> In the end we found that null == blah became more
> plausible with the amount of beer consumed, so I say we keep doing it in
> avalon :D
Ahh, good point! I never though of that, and I see you have done some
proper investigation too.
I must now start changing these in my own code so I can enjoy a few more
beers before I quit coding. ;) Have a nice weekend.
Cheers,
//
Johan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [ot] Re: Coding style question: backwards null checks
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> in java:
>
> 1) it is common practice in C/C++
> 2) it is not common practice in C/C++
> 3) it is common practice in java
> 4) it is not common practice in java
>
> 1-4 are really the most important argument (any way you put it, it makes
> life easier if we are all used to the same thing :D), but no-one
> bothered checking. In the end we found that null == blah became more
> plausible with the amount of beer consumed, so I say we keep doing it in
> avalon :D
Sounds good to me!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[ot] Re: Coding style question: backwards null checks
Posted by Leo Simons <le...@apache.org>.
We had a two-hour discussion on this the other day! (though we watched a
movie in between :D) It makes sense in C and C++. It also makes sense to
people for whom C and C++ makes sense.
The main arguments we found for using or not using
null == blah
0 == blah
MY_CONSTANT == blah
in java:
1) it is common practice in C/C++
2) it is not common practice in C/C++
3) it is common practice in java
4) it is not common practice in java
5) it makes code verification easier in an editor (for example, if you
use an editor made for C++ it might find the '=' error in the
null = blah setup, and not the other way around)
6) the meaning of what you are doing is more clear, since you
are testing whether a constant is the thing you just found
7) the meaning of what you are doing is less clear, since you
are testing whether an object equals a constant and not the
other way around
8) it is not common practice in textbooks (for some reason, we
couldn't think of a textbook that does it this way; though
I'm sure there must be)
1-4 are really the most important argument (any way you put it, it makes
life easier if we are all used to the same thing :D), but no-one
bothered checking. In the end we found that null == blah became more
plausible with the amount of beer consumed, so I say we keep doing it in
avalon :D
cheers!
- Leo
Johan Sjöberg wrote:
> Berin Loritsch wrote:
>> Jeff Turner wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Coding style question: backwards null checks
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
> On Fri, 7 Mar 2003, Berin Loritsch wrote:
>
>> Actually, this *does* have a purpose. In the event that
>> stringToCompare is null, then you would get spurious
>> NullPointerExceptions that are not always easy to trace.
>
> Ohhhh....
>
> The things they just don't teach you in class :)
What class?? When I ended in May 1995 nowhere they teached Java. :-D
>
> *puts into bag of tricks*
Currently it is big. ;-P
Antonio Gallardo
>
> Thanks guys!
>
>
> Tony
Re: Coding style question: backwards null checks
Posted by Tony Collen <tc...@neuagency.com>.
On Fri, 7 Mar 2003, Berin Loritsch wrote:
> Actually, this *does* have a purpose. In the event that
> stringToCompare is null, then you would get spurious
> NullPointerExceptions that are not always easy to trace.
Ohhhh....
The things they just don't teach you in class :)
*puts into bag of tricks*
Thanks guys!
Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Coding style question: backwards null checks
Posted by Tony Collen <tc...@neuagency.com>.
On Fri, 7 Mar 2003, Berin Loritsch wrote:
> Actually, this *does* have a purpose. In the event that
> stringToCompare is null, then you would get spurious
> NullPointerExceptions that are not always easy to trace.
Ohhhh....
The things they just don't teach you in class :)
*puts into bag of tricks*
Thanks guys!
Tony
Re: Coding style question: backwards null checks
Posted by Berin Loritsch <bl...@apache.org>.
Tony Collen wrote:
> On Fri, 7 Mar 2003, Berin Loritsch wrote:
>
> Likewise, I've seen something like this in code... can't remember if it's
> anywhere in Cocoon:
>
> if ( "something".equals(stringToCompare) {
> ...
> }
>
> IMO it seems more straightforward and easier to read if it's:
>
> if ( stringToCompare.equals("something") ) {
> ...
> }
>
> Is this just a matter of style as well? The first way seems goofy if you
> ask me.
Actually, this *does* have a purpose. In the event that
stringToCompare is null, then you would get spurious
NullPointerExceptions that are not always easy to trace.
The "something".equals(somethingElse) guarantees that
you won't get the NullPointerException every time without
resorting to the longer form of:
if ( stringToCompare != null && stringToCompare.equals("something") ) {
....
}
It's a lot more typing to be _truly_ functionally
equivalent. The compiler cannot guarantee that
the stringToCompare variable is never null, so it
will not give you a warning.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Coding style question: backwards null checks
Posted by Stephen Peters <po...@portnoy.org>.
Tony Collen <tc...@neuagency.com> writes:
> Likewise, I've seen something like this in code... can't remember if it's
> anywhere in Cocoon:
>
> if ( "something".equals(stringToCompare) {
[ versus... ]
> if ( stringToCompare.equals("something") ) {
>
> Is this just a matter of style as well? The first way seems goofy if you
> ask me.
Well, the first form works even if stringToCompare is null, the second
one will raise an exception in that case.
--
Stephen L. Peters portnoy@portnoy.org
GPG fingerprint: A1BF 5A81 03E7 47CE 71E0 3BD4 8DA6 9268 5BB6 4BBE
"Poodle: The other white meat." -- Sherman, Sherman's Lagoon
Re: Coding style question: backwards null checks
Posted by Berin Loritsch <bl...@apache.org>.
Tony Collen wrote:
> On Fri, 7 Mar 2003, Berin Loritsch wrote:
>
> Likewise, I've seen something like this in code... can't remember if it's
> anywhere in Cocoon:
>
> if ( "something".equals(stringToCompare) {
> ...
> }
>
> IMO it seems more straightforward and easier to read if it's:
>
> if ( stringToCompare.equals("something") ) {
> ...
> }
>
> Is this just a matter of style as well? The first way seems goofy if you
> ask me.
Actually, this *does* have a purpose. In the event that
stringToCompare is null, then you would get spurious
NullPointerExceptions that are not always easy to trace.
The "something".equals(somethingElse) guarantees that
you won't get the NullPointerException every time without
resorting to the longer form of:
if ( stringToCompare != null && stringToCompare.equals("something") ) {
....
}
It's a lot more typing to be _truly_ functionally
equivalent. The compiler cannot guarantee that
the stringToCompare variable is never null, so it
will not give you a warning.
Re: Coding style question: backwards null checks
Posted by Stefano Mazzocchi <st...@apache.org>.
Tony Collen wrote:
> On Fri, 7 Mar 2003, Berin Loritsch wrote:
>
>
>>Jeff Turner wrote:
>>
>>>Hi,
>>>
>>>Quick question. Why do people put null checks backwards:
>>>
>>> if ( null != this.inputSource ) {
>>>
>>>IMHO it is harder to read than
>>>
>>> if ( this.inputSource != null ) {
>>>
>>>and means exactly the same thing.
>
>
> Likewise, I've seen something like this in code... can't remember if it's
> anywhere in Cocoon:
>
> if ( "something".equals(stringToCompare) {
> ...
> }
>
> IMO it seems more straightforward and easier to read if it's:
>
> if ( stringToCompare.equals("something") ) {
> ...
> }
>
> Is this just a matter of style as well?
no, this is substantially different.
the first will never trigger a nullpointerexception, no matter what the
stringToCompare is since String.equals() is Null-aware and fails nicely
with a 'false' boolean if a string is compared with a null.
Re: Coding style question: backwards null checks
Posted by Tony Collen <tc...@neuagency.com>.
On Fri, 7 Mar 2003, Berin Loritsch wrote:
> Jeff Turner wrote:
> > Hi,
> >
> > Quick question. Why do people put null checks backwards:
> >
> > if ( null != this.inputSource ) {
> >
> > IMHO it is harder to read than
> >
> > if ( this.inputSource != null ) {
> >
> > and means exactly the same thing.
Likewise, I've seen something like this in code... can't remember if it's
anywhere in Cocoon:
if ( "something".equals(stringToCompare) {
...
}
IMO it seems more straightforward and easier to read if it's:
if ( stringToCompare.equals("something") ) {
...
}
Is this just a matter of style as well? The first way seems goofy if you
ask me.
Tony
Re: Coding style question: backwards null checks
Posted by Berin Loritsch <bl...@apache.org>.
Jeff Turner wrote:
> Hi,
>
> Quick question. Why do people put null checks backwards:
>
> if ( null != this.inputSource ) {
>
> IMHO it is harder to read than
>
> if ( this.inputSource != null ) {
>
> and means exactly the same thing.
Yep.
> I think this is a throwback from the days of C, where swapping the
> conditions was a handy way to avoid =/== bugs like:
>
> if ( this.inputSource = null ) {
>
> But in Java, the compiler catches this error:
>
> Found 1 semantic error compiling "Test.java":
>
> 10. if (inputSource = null) {
> <---------------->
> *** Error: The type of this expression, "Source", is not boolean.
I see.
> So is there any other reason for this? Can I do a massive grep for
> 'null !=' and change these?
No, I think that is the major reason.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Coding style question: backwards null checks
Posted by Berin Loritsch <bl...@apache.org>.
Jeff Turner wrote:
> Hi,
>
> Quick question. Why do people put null checks backwards:
>
> if ( null != this.inputSource ) {
>
> IMHO it is harder to read than
>
> if ( this.inputSource != null ) {
>
> and means exactly the same thing.
>
>
> I think this is a throwback from the days of C, where swapping the
> conditions was a handy way to avoid =/== bugs like:
>
> if ( this.inputSource = null ) {
From the Avalon developers, two responses (one humorous):
------------------------------------------------------
From the archives:
>Just a stylistic nit-pick:
>
>I noticed you committed a change that does nothing
>but change the style of the code. Let me explain
>why I do it the way I do.
>
>regarding "if (null != message) ...":
>
>to me this is not semantically correct, it is kind
>of backwards. We are not checking if null is
>message, but if message is null. I also think that
>by keeping it "if (message != null) ..." it is more
>readable and understandable by most English speaking
>folks.
I used to agree .. thou apparently we are wrong ;) (Had an argument with
a professor over this one time ;] ) The reason basically comes down to
expectations. "if( XXX == ... )" where XXX is any immutable-constant
(like integer values, floats, nulls) is meant to facilitate
understanding. It helps you understand the difference between
"constants" and l-vars (or whatever they are called). Students who were
taught "if( XXX == ... )" gain a "deeper" understanding of programming
language. In some languages (namely c/c++) it also has added benefit of
using compiler to check you don't have single '=' etc - thou this is for
all purposes not relevent to java.
------------------------------------------------------
From Leo Simmons:
We had a two-hour discussion on this the other day! (though we watched a
movie in between :D) It makes sense in C and C++. It also makes sense to
people for whom C and C++ makes sense.
The main arguments we found for using or not using
null == blah
0 == blah
MY_CONSTANT == blah
in java:
1) it is common practice in C/C++
2) it is not common practice in C/C++
3) it is common practice in java
4) it is not common practice in java
5) it makes code verification easier in an editor (for example, if you
use an editor made for C++ it might find the '=' error in the
null = blah setup, and not the other way around)
6) the meaning of what you are doing is more clear, since you
are testing whether a constant is the thing you just found
7) the meaning of what you are doing is less clear, since you
are testing whether an object equals a constant and not the
other way around
8) it is not common practice in textbooks (for some reason, we
couldn't think of a textbook that does it this way; though
I'm sure there must be)
1-4 are really the most important argument (any way you put it, it makes
life easier if we are all used to the same thing :D), but no-one
bothered checking. In the end we found that null == blah became more
plausible with the amount of beer consumed, so I say we keep doing it in
avalon :D
cheers!
Re: Coding style question: backwards null checks
Posted by Berin Loritsch <bl...@apache.org>.
Jeff Turner wrote:
> Hi,
>
> Quick question. Why do people put null checks backwards:
>
> if ( null != this.inputSource ) {
>
> IMHO it is harder to read than
>
> if ( this.inputSource != null ) {
>
> and means exactly the same thing.
Yep.
> I think this is a throwback from the days of C, where swapping the
> conditions was a handy way to avoid =/== bugs like:
>
> if ( this.inputSource = null ) {
>
> But in Java, the compiler catches this error:
>
> Found 1 semantic error compiling "Test.java":
>
> 10. if (inputSource = null) {
> <---------------->
> *** Error: The type of this expression, "Source", is not boolean.
I see.
> So is there any other reason for this? Can I do a massive grep for
> 'null !=' and change these?
No, I think that is the major reason.