What is the argument to put constants in if statements first?

I looked at the C ++ code example for the hardware interface I'm working with, and noticed a lot of statements in the following lines:

if ( NULL == pMsg ) return rv; 

I'm sure I heard people say that setting a constant first is a good idea, but why? Is it just that if you have a great expression, can you quickly see what you are comparing, or is there more?

+55
c ++ coding-style if-statement constants
Jan 26 '10 at 10:18
source share
8 answers

So that you do not mix comparison (==) with assignment (=).

As you know, you cannot assign a constant. If you try, the compiler will give you an error message.

In principle, this is one of the protective methods of programming. To protect yourself from yourself.

+75
Jan 26 '10 at 10:19
source share

To stop recording:

  if ( pMsg = NULL ) return rv; 

by mistake. A good compiler will warn you about this, so most people don’t use the “permanent first” way, because they are hard to read.

+29
Jan 26 '10 at 10:19
source share

It stops the single = assign error.

For example,

 if ( NULL = pMsg ) return rv; 

will not compile where

 if ( pMsg = NULL) return rv; 

compiles and gives you headaches

+8
Jan 26 '10 at 10:20
source share

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

Someone writes, say, a string class and decides to add a translation 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 programming template constant == variable "protective":

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

This is IMO, a more insidious problem than random assignment, because you cannot tell from the call site that something is clearly wrong.

Of course, the real lessons are:

  • Do not write your own string classes.
  • Avoid implicit translation operators, especially when executing (1).

But sometimes you are dealing with third-party APIs that you cannot control. For example, the _bstr_t class, common in Windows COM software, suffers from this drawback.

+8
Jan 26 '10 at 20:39
source share

When the constant is the first, the compiler will warn you if you accidentally write = , not == , since it is illegal to assign a value to a constant.

+7
Jan 26 '10 at 10:19
source share

They said: "To prevent confusion between attribution and comparison."

In fact, I think this is nonsense: if you are so disciplined that you remember to set a constant on the left side, you definitely will not mix '=' with '==', will you?;)

+2
Jan 26 '10 at 10:29
source share

Warning compilers are good, but some of us in the real world cannot afford to treat warnings as errors. Reversing the order of variables and constants means that this simple miss always displays as an error and prevents compilation. You get used to this template very quickly, and the error that it protects is subtle, which is often difficult to find after introduction.

+2
Jan 26 '10 at 11:30
source share

I forgot the article, but the quote was something like: "Obviously, it is easier to remember, to first set a constant, than it remembers, use ==";))

0
Jan 26 '10 at 23:41
source share



All Articles