Why do some experienced programmers write comparisons with the value before the variable?

Question

Possible Duplicates:
How to check for equals? (0 == i) or (i == 0)
Why does one often see “null != variable” instead of “variable != null” in C#?

I've been having a look at an odd tutorial here and there as well as some DirectX code and noticed that many experienced C++ programmers write expressions in the following way:

(<constant> == <variable>)

rather than what my conventional wisdom seems to prefer:

(<variable> == <constant>)

E.g. if (NULL == ptr) rather than if (ptr == NULL). I prefer the second alternative, if there are no other reasons for choosing the former, my reason being that the variable seems to be the "receiving" end of the expression.

But I suspect the former is used to avoid inadvertently assigning the value of the constant to the variable by using = rather than ==. Would that be correct?

Answer 1

That used to be the case, yes. Of course, nowadays almost all compilers warn about assignments in if() conditions, so the advantage is only there for people who routinely suppress warnings.

Answer 2

Yes, that's correct. It's to detect the typo of = instead of ==.

Answer 3

This has been dubbed as a "Yoda Conditional"!

See here https://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined

I really like that term because:

if(Light::On == light)

Reads as:

"If on is the light"

As stated already, this is used to prevent incorrect assignment. It could be argued that this practice is archaic based on modern IDEs but I still think it is good practice.

Answer 4

its because you cannot assign a value to a constant, so if by mistake you put = instead of == the compiler throws an error, alerting you

Answer 5

That is a common justification, as is the argument that you don't want to push the constant off to the far right of the screen with a long-winded expression. The latter argument has never sounded particularly convincing to me, and the former isn't really valid these days, since any self-respecting compiler will issue warnings (you do compile with warnings-as-errors, don't you? :-).

EDIT: I just came across the new Xcode 4 preview, and just look at the example they chose to exemplify their new "Fix-it" feature!

_{(source: apple.com)}

Answer 6

To catch the difference between assigning and comparing.

If you mean:

if (ptr == foo)

but type

if (ptr = foo)

if will still be valid code, since ptr = foo will evaluate to a boolean check on ptr after it has been set to the value of foo. Obviously, you don't want this.

However, I find it hurts readability considerably, and given that most IDE's and preprocessors will catch this anyway, never use this style.

Answer 7

It avoids that you write var = NULL. Writing NULL = var will yield an error. So you're right :-)

Answer 8

Check out the top-rated answer to this question..

https://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined

They've dubbed this coding style "Yoda Conditions".

Answer 9

Catching assignment is a major reason Yoda conditions are used, but there are others: In C++ the operator is invoked on the LHS operand. As constants are typically const (duh), or primitives, this limits the possibility of non-sensical operations. One example is = on a primitive literal, such as the common reason given (1 = a), but this will include operator=() const, or whatever operator is used for non-POD types.

Answer 10

With a language such as VB 6.0 which does not not have distinct assignment and comparison operators,

a = 2

' Will compile, whether you mean a is assigned 2 or whether you are comparing a with 2 If you meant compare, there is a likelihood that a runtime error ensues.

' For Assignment if you always write

a = 2

' And for Assignment if you always write

2 = a

' You eliminate the Compile-success and runtime-error scenario.

But, this is just the tip: the visual hint is unavailable when you have an expression like

a = b ' Comparison or assignment?

C# has: - different assignment (=) & comparison (==) symbols - comparisons have to be wrapped in brackets.

Then this becomes a non-issue.

Answer 11

You're right - it's to trigger a compiler error if you mistype "==" as "=", since an assignment will always return true. While this will usually be easy to notice and debug, once in a while it will turn into a very hard to detect bug, think of this:

#define OK 2 // Or something...
[...]
while(status = OK){
    // This loop will never end
    // Even if you change the value of status within it
    [...]
}

That can be a nasty bug to find, especially if the block belonging to the offending statement is long (imagine looking for all the possible reasons why status is always staying OK).

If on the other hand you used:

while(OK = status){

That would throw a compiler error, since you cannot assign a value to a constant.

This practice is sometimes referred to as Yoda conditions, since it juxtaposes the object and subject. Like "if status is OK" vs "if OK is status" and "the sky is blue" vs "blue is the sky" - the latter being something Yoda might say.

Answer 12

As a java developer I tend to write expressions like this:

   //primitive check
   if(constant == variable)

   //Object check
   if(constant.equals(variable))

This is particularly important for the object because the expression doesn't error if the variable is null. If the expression were in the other order, a null variable would error. I maintain consistency and do the same order for primitives.