Question

在探索msdn网站时，他们正在使用大多数条件检查位置（NULL == bCondition）。

使用这些符号的目的是什么？

请提供一些样本来解释这些。

感谢。

Answer 1

使用NULL == condition在拼写错误的情况下提供更有用的行为，当意外使用赋值运算符=而不是比较运算符==时：

if (bCondition = NULL)  // typo here
{
 // code never executes
}

if (NULL = bCondition) //  error -> compiler complains
{
 // ...
}

C编译器在前一种情况下发出警告，在许多语言中都没有这样的警告。

Answer 2

它被称为Yoda Conditions。（original link，您需要高代表才能看到它。）

这意味着在意图进行相等比较=的情况下防止意外分配==。如果你习惯性地坚持Yoda并通过编写=而不是==来输入拼写错误，代码将无法编译，因为你无法分配到右值。

值得尴尬吗？有些人不同意，他们说编译器在条件表达式中看到=时会发出警告。我说在我的一生中只发生了两三次这样的错误，这并不能证明我将生命中所写的所有MLOC都改为这个惯例。

Answer 3

许多人更喜欢编写NULL == bCondition，以便他们意外地不将NULL值赋给bCondition。

因为拼写错误而不是写

bCondition == NULL

他们最终写作

bCondition = NULL // the value will be assigned here.

如果是

NULL = bCondition // there will be an error

Answer 4

没有区别。这是一种古老的防御性编程方式，已经淘汰了20多年。目的是在比较两个值时防止意外键入=而不是==。迁移到C的Pascal程序员特别容易写这个错误。

从1990年发布的Borland Turbo C开始，当你设法输入这个bug时，每个已知的编译器都会警告“可能不正确的分配”。

所以写作（NULL == bCondition）并不比相反的更好或更差，除非你的编译器非常古老。您无需为任何特定顺序编写它们而烦恼。

没有理由这样做。这是C语言的一个完全多余，冒险和丑陋的特性。所有行业事实上的编码标准都禁止在内部条件下进行分配。

参考文献：

Answer 5

这只是一个很好的防御措施。有些人也可能觉得阅读起来更方便。如果错误的赋值而不是相等运算符，编译器将尝试修改NULL，这不是左值并将产生错误消息。使用bCondition = NULL时，编译器可能会产生一个关于将赋值用作真值的警告，这个消息可能会丢失并且不会引起注意。

Answer 6

虽然通常是，variable == value和value == variable之间没有区别，原则上不应该有，在C ++中有时可能会有区别如果涉及运算符重载。例如，虽然==预计是对称的，但是有人可能会编写一个不是的病态实现。

Microsoft的_bstr_t字符串类在其operator==实现中存在不对称问题。