Question

我正在查看我正在使用的硬件接口的一些示例C ++代码，并注意到以下几行中的大量语句：

if ( NULL == pMsg ) return rv;

我确信我听过有人说将常数放在第一位是个好主意，但为什么呢？是不是如果你有一个大的陈述，你可以很快看到你正在比较什么或者还有更多呢？

Answer 1

这样就不会将比较（==）与赋值（=）混合在一起。

如您所知，您无法分配常量。如果您尝试，编译器会给您一个错误。

基本上，它是防御性编程技术之一。为了保护自己免受自己的伤害。

Answer 2

阻止你写作：

 if ( pMsg = NULL ) return rv;

错误。一个好的编译器会警告你这一点，所以大多数人不会使用“常量优先”的方式，因为他们发现很难阅读。

Answer 3

它会停止single =赋值错误。

例如，

if ( NULL = pMsg ) return rv;

将无法编译，

if ( pMsg =  NULL) return rv;

会编译并让你头疼

Answer 4

为了澄清我在一些评论中所写的内容，这是不在C ++代码中执行此操作的原因。

有人写了一个字符串类，并决定将一个强制转换操作符添加到const char*：

class BadString
{
public:
   BadString(const char* s) : mStr(s) { }

   operator const char*() const { return mStr.c_str(); }

   bool operator==(const BadString& s) { return mStr == s.mStr; }

   // Other stuff...

private:
   std::string mStr;
};

现在有人盲目地应用constant == variable“防御性”编程模式：

BadString s("foo");

if ("foo" == s) // Oops.  This compares pointers and is never true.
{
   // ...
}

这是IMO，这是一个比意外分配更隐蔽的问题，因为你无法从呼叫网站告诉任何事情显然是错误的。

当然，真正的教训是：

不要编写自己的字符串类。
避免使用隐式转换运算符，尤其是在执行（1）时。

但有时您正在处理无法控制的第三方API。例如，Windows COM编程中常见的_bstr_t字符串类就存在这个缺陷。

Answer 5

当常量为第一个时，如果您不小心写=而不是==，编译器会发出警告，因为将值赋给常量是非法的。

Answer 6

他们说，“防止分配和比较的混合”。

实际上我认为这是无稽之谈：如果你如此纪律，你不要忘记在左侧放置常数，你绝对不会混合用'=='来'='，对吗？ ;）

Answer 7

编译器输出警告是好的，但现实世界中的一些人不能将警告视为错误。反转变量和常量的顺序意味着这个简单的滑动总是显示为错误并阻止编译。你很快习惯了这种模式，它所防止的错误是一个微妙的错误，一旦引入就很难找到。

Answer 8

我忘记了这篇文章，但引用的内容类似于：“显然它更容易记住将常量放在第一位，而不是记住要使用==”;））

将常量放在if语句中的原因是什么？

8 个答案: