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.

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.

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.

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.

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).