Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Which is better way for checking null?  RSS feed

 
abhijit Ohal
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Which is better way for checking null ?
One of my friend told me that for performances improvement, never used the 1. way.?
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ignore any performance benefit (though I'd be very surprised should your friend be able to demonstrate a difference), the second way is just an overly confusing double negative. Performance may or may not change, but I bet a developer somewhere down the line misreads this and makes a mistake accordingly.
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Abhijit,

I'd be very very surprised, too, if there would be a noticeable performance difference! These stories are very often just myths from old times With a modern JIT compiler and modern JVMs you can't even know exactly what is the binary outcome of your Java code. There's much optimization a good compiler can do and in fact does for you so you can't really tell everything that's going on under the hood just from the source code. Unlike in languages like "C" it may even hinder the compiler if you include these manual "optimizations". At most it will irritate other developers, like Paul said!

Anyway why does your friend think that particularly the second way should be better regarding performance? There's even one additional operator in this expression! So from the perspective of the source code it's very arguable where an advantage in performance should be here.

Marco
[ May 19, 2008: Message edited by: Marco Ehrentreich ]
 
abhijit Ohal
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks you Paul , Marco
While doing code review he told me this ,I was also surprise with this when he told me that .I asked him what is wrong in it but he can't justify it.
I would like to share the code below
I have done coding using First way.but he told me it is wrong made it by second way.

 
Kenneth Gustafsson
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Like people have said, the optimizer will take care of these trivial situations. Only optimize where it counts. Most often this is where your profiler tells you that you have a problem.

Without any optimizing at all. Worst case for your code is two comparisons and your friends code three. He also has more logical operators. If anything your friends code is slower, though it's unimportant. Also notice that your code is much easier to read. You win! (If I were the judge, which I ain't)

Your friend seems to like to flex his boolean muscles and create some overly complicated solutions.
[ May 19, 2008: Message edited by: Kent Larsson ]
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In this example once again the source code of the second method is equal or more complicated than the first variant. Even if there's a short circuit in evaluating the boolean && expression it's definitely at least as complicated as the first code. As I said this doesn't necessarily tell you what byte code the compiler might exactly generate from it but I think it should be obvious that method 2 has no real advantages despite of confusing other people

Generally a good advice today is to focus on readable, maintainable and clear code. Optimize only when and where it's useful and necessary. If there's no bottleneck there's no reason to produce more difficult code because of some questionable optimizations. And it would be wise to use a profiler for locating real performance problems and not just suppose where a problem could be.

I think you should do what you think is the right way as long as your friend can't convince you with facts!

Marco
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not only is the second version longer, it's needlessly longer! Since

! (books != null)

means exactly the same thing as

books == null,

the second null check is redundant. Even if you wanted to use the double negative for some bizarre reason, why wouldn't you just write

if(!(books!=null) || books.length <=0)){

Finally since array lengths can never be less than zero, why not use "==" rather than "<=" ?

If you actually have someone sitting in your company's code reviews turning perfectly good code into mush -- and yet not pointing out the "<=" thing -- then somebody needs to have a little talk with that person.
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

! (books != null)

means exactly the same thing as

books == null


This is simple boolean algebra. There are a lot of rules to transform boolean expressions to equivalent simpler expressions without the loss of its meaning.

As Ernest says this is something your friend should probably know if he does code reviews

Marco
 
Kenneth Gustafsson
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well maybe they have peer-reviews of code (wich I like myself) so it might not be someone they consider an expert making these "improvements". Of course it's possible they've fallen for the "if it sounds like an expert it must be one" syndrome too.
[ May 20, 2008: Message edited by: Kent Larsson ]
 
rajesh bala
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looking at this I could recall the statement "Premature optimization is the root cause of all evil"

Worst part here is, the code would also become HIGHLY UGLY and UNREADABLE.

I bet there won't be any noticeable performance difference with this code. And I believe the code review happened on April 1st. (just joking)

~Rajesh.B
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In one code review for a major company they requested I place all variable declarations in alphabetical ordering at the top of the code with exact tabbing or they wouldn't accept it, you could write any gibberish you liked as long as you did that.

I'm glad I don't work with your code reviewer ;-)

For the example :

I ran the byte code for both my compiler spat out the same number of instructions (though not the same ones), so you'd be left with if your JVM can execute some instructions faster than others. I was just interested to see if it could optimize them to the same thing, the answer to which is no for my compiler.
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by rajesh bala:
Looking at this I could recall the statement "Premature optimization is the root cause of all evil"

Worst part here is, the code would also become HIGHLY UGLY and UNREADABLE.

I bet there won't be any noticeable performance difference with this code.


Ragesh is 100% correct. If there is any significant performance difference here, I'll buy you and Ragesh a beer
 
steve souza
Ranch Hand
Posts: 862
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Code reviews should be 2 way communications. In this case the reviewer gave advice that is questionable in that he is recommending that you make the code look worse on a questionable premise that performance will improve.

With all due respect to your friend I believe developers that make performance claims with no evidence are usually poor programmers across the board.

The reason for this is that in software development, and other sciences we must make hypothesis's, and come up with a test to confirm or refute the hypothesis. Your friend likes coming up with hypotheses, but doesn't like testing them. It is hard to be a good developer with such unscientific practices. This approach will lead you to thinking pigs fly too.
[ May 20, 2008: Message edited by: steve souza ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!