Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I notice that someone in my organization programs comparisons like:

if (100 == myVariable)

rather than:

if (myVariable == 100)

He claims the former is quicker in languages like C++. I can't find any evidence. We program in C#.

Is this true for any programming language?

share|improve this question
3  
The former is colloquially known as a "Yoda Condition". Originally posted over at StackOverflow, but sadly deleted. –  Jesse C. Slicer Sep 27 '12 at 17:47
    
1  
That's a new twist to foist this silly style. It isn't faster, and yes, it does do more harm than good. –  David Hammen Sep 27 '12 at 23:03
add comment

5 Answers

up vote 22 down vote accepted

No, it is not "quicker": compilers will translate both expressions into the same code.

Some time ago the first pattern has been suggested to people coming to C from other languages where comparing objects required a single =. The idea was to protect them from making this mistake:

if (myVariable = 100)

This is legal, but it assigns 100 to myVariable instead of comparing myVariable to 100. If you make it a habit to put 100 ahead of myVariable, the compiler will trigger an error, because

if (100 = myVariable)

is illegal.

Modern compilers issue warnings when they see an assignment in place of an equality check ==. You can silence the warning in cases when you do want to use an assignment inside an if by adding a second set of parentheses around your assignment expression.

Moreover, the construct is not useful in C# at all, because if (myVariable = 100) is not legal.

share|improve this answer
add comment

Compare disassembly:

if (cmdline == NULL)
    cmp         dword ptr [ebp-138h],0 
    jne         ........

To:

if (NULL == cmdline)
    cmp         dword ptr [ebp-138h],0 
    jne         ........

No difference whatsoever.

The sole reason for "if (const == variable)" order is to catch accidental mistypes of "=" for "==", but your compiler, with the appropriate warning level set (you do have the appropriate warning level set? Good, just checking) will catch those anyway.

Worse, aside from being as unreadable as the Voynich Manuscript, it can lead the programmer into a false sense of safety. Witness:

int a = GetMeAnInteger ();
int b = GetMeAnotherInteger ();

if (a = b)

Ha! Gotcha!

So - not any faster, false sense of safety, makes your fellow programmers want to gouge their eyes out.

Or on the other hand you could just ramp up your warning level and catch them all anyway.

share|improve this answer
add comment

There is one case where there's a difference in C++, and that's if the variable is of an user-defined type, you've got the possibility of overloaded equality testing operators or an operator with a biased implementation.

bool operator == (int a, T b);
bool operator == (T a, int b);

They could have different implementations, have one forward to the other, or per For vanilla symmetric comparison, there shouldn't be any differences.

share|improve this answer
    
+1 for raising == overloading. –  Jimmy Shelter Nov 6 '12 at 19:21
add comment

Short Answer: No, there is no difference. Both comparisons in example above have same effect.

It is translated to compiler with the same logic of comparison. Thus, they are identical in speed.

What makes difference is the order of operation. Thus, to avoid the operation order issues, it is a good practice to use brackets. In addition, you will get compiler warning in C# .NET if there is a wrong syntax used.

share|improve this answer
    
Can you expand on what you mean by "operation order issues"? Also, most compilers tend to throw errors on invalid syntax ;) –  phant0m Oct 1 '12 at 13:46
add comment

In today's multi-core, out-of-order-execution world, you can't count on microefficiencies like this any more. Even if it did save a cycle or two, there's no guarantee when the instruction will be scheduled, or if the cache line holding your variable will be locked (or flushed). I'm not even sure how much more efficient short-circuit evaluation is any more (for simple comparisons).

share|improve this answer
    
...or you could look at the disassembly and realise that they're identical. –  Jimmy Shelter Nov 6 '12 at 19:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.