【发布时间】：2011-03-02 13:28:22
【问题描述】：
在Java中，哪个会更有效，有什么区别？
if (null == variable)
或
if (variable == null)
【问题讨论】：
-
顺便说一句，Java 中是
null，而不是NULL -
@ryanprayogo - 可能是一个常数...
标签： java null if-statement
【发布时间】：2011-03-02 13:28:22
【问题描述】：
（类似于这个问题：Difference between null==object and object==null）
我会说这两个表达式在性能上绝对没有区别。
然而，有趣的是，编译后的字节码（由 OpenJDKs javac 发出）在这两种情况下看起来有点不同。
对于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
对于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
正如@Bozho 所说，variable == null 是最常见、默认和首选的样式。
然而，对于某些情况，我倾向于将null 放在前面。比如下面这种情况：
String line;
while (null != (line = reader.readLine()))
process(line);
【讨论】：
-
+1 不错的发现...但性能方面还是一样？ :)
-
我不知道。检查 JIT 编译器的输出，比如 suns java 的 x86 实现，然后一劳永逸地找出来会很酷：D 你知道怎么做吗？
-
没有。 :)（我仍然想知道为什么这个答案没有得到更多的支持..）
-
Bozho，如果有帮助的话，我可以对你的投票投反对票；) 我无法证明这一点，但我相信不同版本的 JDK 会产生不同优化的字节码。 IE。我不明白为什么另一个编译器不应该为两者生成相同的字节码。
-
@Stroboskop，好吧，java 编译器从来没有在优化字节码上付出太多的努力。基本上，大多数编译器只是将 java 代码简单地转换为字节码，原因很简单，优化应该推迟到硬件等已知的 JIT 编译。也就是说，我怀疑这两种情况生成的机器代码会有所不同。我的意思是，它们在语义上是等价的，并且足够简单，无论如何都可以编译成最有效的机器代码。
这称为"Yoda Conditions"，目的是防止您意外使用赋值 (=) 而不是相等检查 (==)。
【讨论】：
-
@assylias 除了变量是 Booleanm xD
-
@assylias 这是真的，但布尔 x=true; if(x=null) 有效
-
@nachokk 我明白了——在这种情况下，它会抛出 NPE。很公平。
-
SO 链接返回“页面未找到”
没有区别。
if (variable == null) 是 (imo) 一种更好的编程风格。
请注意，null 在 Java 中是小写的。
【讨论】：
-
是的，我同意。
if (null == variable)将是尤达风格:) 在这里解释：stackoverflow.com/questions/… -
@b.roth // 找不到页面。很遗憾。
没有区别
(null == variables)
有时在过去的美好时光中使用（C语言）
避免写作：
(variable = NULL)错了
【讨论】：
简短回答：没有区别。
更长的答案：存在风格上的差异，这是相当主观的。有些人认为常量应该放在左边作为防御风格，以防你将== 输入错误=。有些人认为常量应该是正确的，因为它更自然和可读。
设计良好的语言结合良好的编译器和静态分析工具，可以最大限度地减少偏执，因此您应该编写最易读和最自然的代码，即右侧的常量。
相关问题
下次请使用搜索功能。
【讨论】：
第一个是 C 的遗留问题，写 if(variable = NULL) 是完全合法的
【讨论】：
-
这不是真的：null 不是布尔类型，所以它是不合法的
从性能的角度来看没有实质性差异。
但是...如果您打错字并遗漏了一个等号字符怎么办？
foo = null; // assigns foo to null at runtime... BAD!
对
null = foo; // compile time error, typo immediately caught in editor,
developer gets 8 hours of sleep
这是支持在左侧使用 null 开始 if 测试的一个论据。
支持以 null 开始 if 测试的第二个论点是，即使等号右侧的表达式很冗长，代码的读者也很清楚他们正在查看 null 测试。
@aiooba 也指出了第二个论点：
然而，对于某些情况，我倾向于将 null 放在前面。为了 以下情况的实例：
String line;
while (null != (line = reader.readLine()))
process(line);
【讨论】：
我的意见：不要在意这种微不足道的性能优化。如果性能不佳，请找出代码中的真正问题/瓶颈。
【讨论】：
没有任何区别。
【讨论】：