为什么人们使用if（null == var）样式测试？

Question

有些人，通常是那些来自C背景的人，为null代码编写了这样的代码：

if (null == someVar)

相信“正常”风格

if (someVar == null)

可能会被意外编码为

if (someVar = null)

会无意中为null 分配 null而不是 test 。

但是，如果发生错误编码，例如if (someVar = null)：

1. 为了进行编译，唯一的someVar类型可以是Boolean
2. 如果它已编译并执行，则会抛出NullPointerException


为什么这些人都没有意识到“防守”（即螺旋球）的风格根本没有帮助，因为误编码既不会编译也不会运行！？

BTW，作为性能问题，编码if (null == someVar)实际上执行起来稍慢 - 一条指令要慢一些。原因是必须将null压入堆栈进行比较，而“普通”样式使用特殊的“is null”指令。


我知道......不是一个问题。更多的咆哮。但是我想把它放在那里。如果你也相信他们“不那么富有洞察力”，那么就投票赞成。

但是，如果您确实知道答案，我想听听。

Answer 1

因为他们从C带回了这个习惯，

if (someInteger = 0)

是有效的代码，因为C没有布尔值，只有整数（0为假，其他整数都为真）。

if (somePointer = NULL)

也有效，因为在C中，NULL为0。

所以，在C中，这个结构是有意义的。

请注意，在Java中，执行

时也会发生此错误

if (b = true)

而不是

if (b == true)

当然，优秀的Java开发人员永远不会编写上述内容，但会使用

if (b)

Answer 2

写if (null == someVar)没问题，为什么不呢？对于那些从C / C ++背景中采用这种约定的人来说，保持Java的相同约定并不是一个坏主意;特别是如果他们仍在用C / C ++编写;否则他们最终不得不对两种语言使用两种不同的约定，而不是只有一种共同的约定。

简单的习惯问题，没有任何真正的不良副作用。

Answer 3

以这种方式对变量进行范围扩展有时很有用：

if(std::shared_ptr<X> p = q.lock())
{
    // q is valid, I can now use p.

    p->DoSomething();
}

q.lock（）！= 0评估为TRUE。 q.lock（）== 0的计算结果为FALSE。上面给出的编码风格将使意图明确。然而，现在编译器非常聪明地发现了非预期的任务，所以它并不是真的有必要。过去情况并非如此。