12 Answers
12

People often do 1 == evaluated value because 1 is not an lvalue. Meaning that you can't accidentally do an assignment.

Example:

if(x = 6)//bug, but no compiling error
{
}

Instead you could force a compiling error instead of a bug:

if(6 = x)//compiling error
{
}

Now if x is not of int type, and you're using something like C++, then the user could have created an operator==(int) override which takes this question to a new meaning. The 6 == x wouldn't compile in that case but the x == 6 would.

I happen to think doing it that way is a crock, but you're right, that's why people do it that way.
–
Paul TomblinMar 24 '09 at 13:06

Agreed with Paul. Code is less readable that way. Some C++ compilers will issue a warning if you do this, and smartly, C# does not allow it.
–
rlbondMar 24 '09 at 13:09

I have done it before, but mainly because I work on a huge project and it has some warnings we just can't seem to get the time to remove. So I'm afraid such an accidental assingment may happen one day. Or an accidental deletion of a single = char at a random spot.
–
Brian R. BondyMar 24 '09 at 13:13

"Code is less readable that way". Surely that just depends whether you're used to it? If you hate it then of course it's less readable, since you have a small conniption each time you see it. If you like it or don't care, then not so much.
–
Steve JessopMar 24 '09 at 13:22

"Less readable" depends on the rhs. When you use this because switch() is broken, then "if (CONST1 == x) ... else if (CONST2 == x)" is much more readable than the alternative.
–
Aaron DigullaMar 24 '09 at 13:32

In Ruby, Smalltalk, Self, Newspeak, Ioke and many other single-dispatch object-oriented programming languages, a == b is actually a message send. In Ruby, for example, it is equivalent to a.==(b). What this means, is that when you write a == b, then the method == in the class of a is executed, but when you write b == a, then the method in the class of b is executed. So, it's obviously not the same thing:

You can redefine operator==() in C++, too, but making it nonsymmetrical is probably a bad idea. Also see Pete Kirkham's answer citing Prolog and Erlang. You're up to eight languages where a==b is not necessarily the same as b==a.
–
David ThornleyMar 24 '09 at 21:58

I agree that having it non-symmetrical is a bad idea. However, in Ruby, there is no way to do that: == is a method that is always sent to the receiver. You could implement double-dispatch by hand (similar to the Visitor Pattern), and, indeed the numerical classes do that, but you can't enforce it.
–
Jörg W MittagMar 24 '09 at 22:52

In Prolog or Erlang, == is written = and is a unification rather than an assignment (you're asserting that the values are equal, rather then testing that they are equal or forcing them to be equal), so you can use it for an assertion if the left hand side is a constant, as explained here.

So X = 3 would unify the variable X and the value 3, whereas 3 = X would attempt to unify the constant 3 with the current value of X, and be equivalent of assert(x==3) in imperative languages.

That's wrong. I can think of at least 5 languages where that is not the case. And since I don't actually know that many languages, I would guess that there's probably a couple hundred more for which this is also the case.
–
Jörg W MittagMar 24 '09 at 21:41

Jörg W Mittag: just curious, can you give one example where (A == 5) is different from (5 == A)?
–
SergioMar 25 '09 at 12:02

Sometimes in C++ they do different things, if the evaluated value is a user type and operator== is defined. Badly.

But that's very rarely the reason anyone would choose one way around over the other: if operator== is not commutative/symmetric, including if the type of the value has a conversion from int, then you have A Problem that probably wants fixing rather than working around. Brian R. Bondy's answer, and others, are probably on the mark for why anyone worries about it in practice.

But the fact remains that even if operator== is commutative, the compiler might not do exactly the same thing in each case. It will (by definition) return the same result, but it might do things in a slightly different order, or whatever.