What's the reasoning behind putting constants in if statements first?

Question

I was looking at some example C++ code for a hardware interface I\'m working with and noticed a lot of statements along the following lines:

if ( NULL == pMsg )          


        

Answer 1

To clarify what I wrote in some of the comments, here is a reason not to do this in C++ code.

Someone writes, say, a string class and decides to add a cast operator to 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;
};

Now someone blindly applies the constant == variable "defensive" programming pattern:

BadString s("foo");

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

This is, IMO, a more insidious problem than accidental assignment because you can't tell from the call site that anything is obviously wrong.

Of course, the real lessons are:

1. Don't write your own string classes.
2. Avoid implicit cast operators, especially when doing (1).

But sometimes you're dealing with third-party APIs you can't control. For example, the _bstr_t string class common in Windows COM programming suffers from this flaw.

Answer 2

To stop you from writing:

 if ( pMsg = NULL ) return rv;

by mistake. A good compiler will warn you about this however, so most people don't use the "constant first" way, as they find it difficult to read.

Answer 3

Compilers outputting warnings is good, but some of us in the real world can't afford to treat warnings as errors. Reversing the order of variable and constant means this simple slip always shows up as an error and prevents compilation. You get used to this pattern very quickly, and the bug it protects against is a subtle one, which is often difficult to find once introduced.

Answer 4

So that you don't mix comparison (==) with assignment (=).

As you know, you can't assign to a constant. If you try, the compliler will give you an error.

Basically, it's one of defensive programming techniques. To protect yourself from yourself.

Answer 5

It stops the single = assignment bug.

Eg,

if ( NULL = pMsg ) return rv;

won't compile, where as

if ( pMsg =  NULL) return rv;

will compile and give you headaches

Answer 6

They said, "to prevent mixing of assignment and comparison".

In reality I think it is nonsense: if you are so disciplined that you don't forget to put constant at the left side, you definitely won't mix up '=' with '==', would you? ;)