cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Coding style question: backwards null checks
Date Fri, 07 Mar 2003 20:00:12 GMT
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!


Mime
View raw message