这些（bCondition == NULL）和（NULL == bCondition）之间有什么区别？
在探索msdn网站时，大部分条件检查他们正在使用（NULL == bCondition）。
使用这些符号的目的是什么？
请提供一些样品来解释这些。
谢谢。
在错误的情况下，使用NULL == condition提供更有用的行为，当一个赋值运算符=被意外使用，而不是比较运算符== ：
if (bCondition = NULL) // typo here { // code never executes } if (NULL = bCondition) // error -> compiler complains { // ... }
C编译器在前一种情况下给出了警告，在许多语言中没有这种警告。
这就是所谓的尤达条件 。 （ 原来的链接 ，你需要高代表来看看它）。
这是为了防止意外的分配=在平等比较==条件下。 如果你习惯性地坚持Yoda，并用==而不是==写一个错字，代码将无法编译，因为你不能分配给右值。
这是否值得尴尬？ 有人不同意，说当编译器在条件expression式中看到=时会发出警告。 我说在我有生之年，只是发生了两三次这样的错误，这并不能certificate我把这辈子写给这个公约的所有MLOC都改了。
许多人更喜欢编写NULL == bCondition，以便他们不意识地将NULL值分配给bCondition。
由于错字发生，而不是写作
bCondition == NULL
他们最终写作
bCondition = NULL // the value will be assigned here.
的情况下
NULL = bCondition // there will be an error
没有区别。 这是一个古老的防守编程方式，已经过时了20多年。 目的是在比较两个值时防止意外键入=而不是==。 Pascal程序员迁移到C特别容易写这个错误。
从1990年发布的Borland Turbo C开始，每个已知的编译器都会警告“可能不正确的赋值”，当你设法input这个bug的时候。
所以写（NULL == bCondition）不是比相反的更好或更差的做法，除非你的编译器是非常古老的。 你不需要为写任何特定的顺序而烦恼。
你应该打扰，是适应一种编码风格，你永远不会写在if /循环条件内的任务。 没有理由这样做。 这是C语言的一个完全多余，危险和丑陋的特征。 所有行业事实上的编码标准禁止在条件内分配。
参考文献：
- MISRA C：2004 13.1
- CERT C EXP18-C
这只是一个很好的防守措施。 有些人也可能觉得阅读起来比较方便。 在错误的赋值而不是等号运算符的情况下，编译器将尝试修改NULL ，这不是一个左值，并会产生一个错误信息。 当使用bCondition = NULL ，编译器可能会产生一个关于使用一个赋值作为真值的警告，这个消息可能会丢失并且不被注意。
虽然variable == value和value == variable之间通常没有区别，原则上不应该有，在C ++中，如果涉及操作符重载，通常情况下可能会有所不同。 例如，虽然==预计是对称的，但有人可能会写一个不是的病态实现。
微软的_bstr_tstring类在operator==实现中遇到了一个不对称的问题。
