> NB my stanza for repeatedly writing non-null checks is:
> if( stringToCompare == null )
> stringToCompare = "";
> if( stringToCompare.equals("something") ) {
> ...
> }
becomes:
0 aload_0
1 ifnonnull 7
4 ldc #2
6 astore_0
7 aload_0
8 ldc #3
10 invokevirtual #4
Tony Collen <[EMAIL PROTECTED]> 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
> -Original Message-
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
> Sent: Freitag, 7. März 2003 18:50
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Coding style question: backwards null checks
>
> > if ( "something".equals(stringToCompar
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'
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
conditio
> 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.
>
> O
>
> The things they just don't teach you in class :)
What clas
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 (
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.
O
The things they just don't teach you in class :)
*puts into bag of tri
Tony Collen <[EMAIL PROTECTED]>
> 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("somet
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(
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
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
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
con
13 matches
Mail list logo
