45

In Java, which will be more effective, and what are the differences?

if (null == variable)

or

if (variable == null)
Sildoreth
  • 1,883
  • 1
  • 25
  • 38
Apache
  • 1,796
  • 9
  • 50
  • 72

9 Answers9

75

(Similar to this question: Difference between null==object and object==null)

I would say that there is absolutely no difference in performance between those two expressions.

Interestingly enough however, the compiled bytecode (as emitted by OpenJDKs javac) looks a bit different for the two cases.

For boolean b = variable == null:

 3: aload_1               // load variable
 4: ifnonnull 11          // check if it's null
 7: iconst_1              // push 1
 8: goto 12           
11: iconst_0              // push 0
12: istore_2              // store

For boolean b = null == variable:

 3: aconst_null           // push null
 4: aload_1               // load variable
 5: if_acmpne 12          // check if equal
 8: iconst_1              // push 1
 9: goto 13
12: iconst_0              // push 0
13: istore_2              // store

As @Bozho says, variable == null is the most common, default and preferred style.

For certain situations however, I tend to put the null in front. For instance in the following case:

String line;
while (null != (line = reader.readLine()))
    process(line);
aioobe
  • 413,195
  • 112
  • 811
  • 826
  • 1
    +1 good find... but performance-wise it's still the same? :) – Bozho Jun 11 '10 at 08:21
  • I don't know. It would be cool to inspect the output of the JIT compiler for, say, the x86 implementation of suns java, and figure it out once and for all :D You know how to do that? – aioobe Jun 11 '10 at 08:30
  • 2
    no. :) (I still wonder why this answer isn't more upvoted..) – Bozho Jun 11 '10 at 08:31
  • I can downvote yours, Bozho, if that helps ;) And i can't prove it, but i believe different versions of the JDK would produce differently optimized byte code. I.e. i don't see why another compiler shouldn't produce the same byte code for both. – Stroboskop Jun 11 '10 at 08:38
  • @Stroboskop, well, java compilers never put *that* much effort into optimizing the bytecode. Basically, most compilers just have a quite naive translation of java-code to bytecode, for the simple reason that the optimization should be deferred to the JIT compilation in which hardware etc is known. That is, I doubt the produced machine code will be different for the two cases. I mean, they're semantically equivalent, and simple enough to be compiled into the most efficient machine code possible anyway. – aioobe Jun 11 '10 at 09:55
  • From what I see, the second set of bytecode is more processor intensive. The first set only pushes one value onto the stack then compares it to null. The second one pushes TWO values on the stack (one being null), then compares them together. The fact that there are two pushes instead of one, plus the one additional byte of bytecode, should add a tiny bit of overhead. This could be tested by running this in a fairly large loop (i.e. 1 billion) and comparing the time each loop takes. – Brain2000 Dec 02 '15 at 02:34
  • @Brain2000, you seem to be assuming that the bytecode is interpreted. The JIT compiler has been around [for almost 20 years now](http://stackoverflow.com/questions/692136/when-did-java-get-a-jit-compiler). – aioobe Dec 02 '15 at 08:31
  • @aioobe You're right. I ran a test with 100 million iterations creating a random one character string comparing it to null, and both ways of comparing null are within the same timeframe. I did find it interesting that if I loop this test multiple times without restarting the JVM, the first time is slow (expected), the second time is faster (also expected), but the third and fourth time continuously get faster. It plateaus after that. – Brain2000 Dec 02 '15 at 22:49
  • [How do I write a correct micro-benchmark in Java?](http://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java) – aioobe Dec 03 '15 at 07:50
23

That's called "Yoda Conditions" and the purpose is to prevent you from accidentally using assignment (=) instead of equality checking (==).

Community
  • 1
  • 1
Edward Dale
  • 29,597
  • 13
  • 90
  • 129
19

No difference.

if (variable == null) is (imo) a better programming style.

Note that null is lowercase in Java.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
13

no difference

(null == variables) was sometimes used in good old times (C language) to avoid writing: (variable = NULL) by mistake

dfens
  • 5,413
  • 4
  • 35
  • 50
8

Short answer: no difference.

Longer answer: there is stylistic difference which is rather subjective. Some people argue constants should be in the left as a defensive style just in case you mistyped == into =. Some people argue constants should be in the right because it's more natural and readable.

A well designed language combined with a good compiler and static analysis tools, paranoia can be minimized, so you should write the most readable and natural code, which would be the constant on the right.

Related questions

Please use the search function next time.

Community
  • 1
  • 1
polygenelubricants
  • 376,812
  • 128
  • 561
  • 623
7

The first is a hang over from C where it is perfectly legal to write if(variable = NULL)

Robert
  • 8,406
  • 9
  • 38
  • 57
6

There is no material difference from a performance perspective.

However... what if you made a typo and missed a single equals character?

foo = null; // assigns foo to null at runtime... BAD!

versus

null = foo; // compile time error, typo immediately caught in editor,
developer gets 8 hours of sleep

This is one argument in favor of beginning an if test with null on the left hand side.

The second argument in favor of beginning an if test with null is that it's made very clear to the reader of the code that they are looking at a null test, even when the expression on the right of the equals sign is verbose.

@aiooba points this second argument out as well:

For certain situations however, I tend to put the null in front. For instance in the following case:

String line;
while (null != (line = reader.readLine()))
    process(line);
Robert Christian
  • 18,218
  • 20
  • 74
  • 89
1

My opinion: Don't care about such insignificant performance optimizations. If you have bad performance, find and target the real problems/bottlenecks in your code.

chiccodoro
  • 14,407
  • 19
  • 87
  • 130
-1

There is not any difference。

Code.....
  • 9
  • 1