问题
This is probably a silly question, but curiosity has gotten the better of me. I've been seeing code lately that seems to "reverse" the order of expressions for relational operators e.g.:
if (0 == someVariable)
As opposed to what I normally see/write:
if (someVariable == 0)
To me, the second method seems more readable and intuitive, so I'm wondering if there's some reason I'm seeing the first method? Logically, both statements evaluate to the same result, so is it just a matter of personal preference how they're written?
回答1:
I understand that this is personal preference. Although by putting the variable second you can ensure that you don't accidentally assign the constant to the variable which used to concearn c developers. This is probably why you are seeing it in c# as developers switch language.
回答2:
Order does not matter, however, the former implies that it s the zero you're checking. Convention dictates the use of hte latter.
回答3:
The main reason in C and C++ is that it is easy to type
if (someVariable = 0) {
...
}
which always fails and also sets someVariable to 0.
I personally prefer the variable-first style because it reads more naturally, and just hope I don't forget to use == not =.
Many C and C++ compilers will issue a warning if you assign a constant inside an if.
Java and C# avoid this problem by forbidding non-boolean expressions in if clauses.
Python avoids this problem by making assignments a statement, not an expression.
回答4:
The first method exists as a way to remind yourself not to do assignments in an IF statement, which could have disasterous consequences in some languages (C/C++). In C# you'll only get bitten by this if you're setting booleans.
Potentially fatal C code:
if (succeeded = TRUE)
{
// I could be in trouble here if 'succeeded' was FALSE
}
In C/C++, any variable is susceptible to this problem of VAR = CONSTANT when you intended VAR == CONSTANT. So, it is often the custom to reorder your IF statement to receive a compile error if you flub this up:
if (TRUE = succeeded)
{
// This will fail to compile, and I'll fix my mistake
}
In C# only booleans are susceptible to this, as only boolean expressions are valid in an if statement.
if (myInteger = 9)
{
// this will fail to compile
}
So, in the C# world it isn't necessary to adopt the CONSTANT == VAR style, unless you're comfortable with doing so.
回答5:
In addition to equality I often come across code like
if (0 > number)
or
if (NULL != pointer)
where there isn't even any danger of making a mistake in C/C++! It's one of those situations where a well-intentioned teaching technique has turned into a plain bad habit.
回答6:
The latter format is a left-over from C-syntax, where, if you inadvertently left out one of the equals-signs, it did an assignment, instead of a comparison.
However, you can of course not assign to a numeric literal, so if you wrote it like the second example, you would get a compiler error, and not a bug.
In C#, however, you cannot inadvertently do this, so it doesn't really matter.
来源：https://stackoverflow.com/questions/91994/relational-operator-expression-order