为什么在 C # 中经常看到“ null! = variable”而不是“ variable! = null”？

I guess this is a C programmer that has switched languages.

In C, you can write the following:

int i = 0;
if (i = 1)
{
...
}

Notice the use of a single equal sign there, which means the code will assign 1 to the variable i, then return 1 (an assignment is an expression), and use 1 in the if-statement, which will be handled as true. In other words, the above is a bug.

In C# however, this is not possible. There is indeed no difference between the two.

In earlier times, people would forget the '!' (or the extra '=' for equality, which is more difficult to spot) and do an assignment instead of a comparison. putting the null in front eliminates the possibility for the bug, since null is not an l-value (I.E. it can't be assigned to).

Most modern compilers give a warning when you do an assignment in a conditional nowadays, and C# actually gives an error. Most people just stick with the var == null scheme since it's easier to read for some people.

It's a hold-over from C. In C, if you either use a bad compiler or don't have warnings turned up high enough, this will compile with no warning whatsoever (and is indeed legal code):

// Probably wrong
if (x = 5)

when you actually probably meant

if (x == 5)

You can work around this in C by doing:

if (5 == x)

A typo here will result in invalid code.

Now, in C# this is all piffle. Unless you're comparing two Boolean values (which is rare, IME) you can write the more readable code, as an "if" statement requires a Boolean expression to start with, and the type of "x=5" is Int32, not Boolean.

I suggest that if you see this in your colleagues' code, you educate them in the ways of modern languages, and suggest they write the more natural form in future.

To me it's always been which style you prefer

@Shy - Then again if you confuse the operators then you should want to get a compilation error or you will be running code with a bug - a bug that come back and bite you later down the road since it produced unexpected behaviour

One more thing... If you are comparing a variable to a constant (integer or string for ex.), putting the constant on the left is good practice because you'll never run into NullPointerExceptions :

int i;
if(i==1){        // Exception raised: i is not initialized. (C/C++)
doThis();
}

whereas

int i;
if(1==i){        // OK, but the condition is not met.
doThis();
}

Now, since by default C# instanciates all variables, you shouldn't have that problem in that language.

There is a good reason to use null first: if(null == myDuck)

If your class Duck overrides the == operator, then if(myDuck == null) can go into an infinite loop.

Using null first uses a default equality comparator and actually does what you were intending.

(I hear you get used to reading code written that way eventually - I just haven't experienced that transformation yet).

Here is an example:

public class myDuck
{
public int quacks;
static override bool operator ==(myDuck a, myDuck b)
{
// these will overflow the stack - because the a==null reenters this function from the top again
if (a == null && b == null)
return true;
if (a == null || b == null)
return false;


// these wont loop
if (null == a && null == b)
return true;
if (null == a || null == b)
return false;
return a.quacks == b.quacks; // this goes to the integer comparison
}
}

Like everybody already noted it comes more or less from the C language where you could get false code if you accidentally forget the second equals sign. But there is another reason that also matches C#: Readability.

Just take this simple example:

if(someVariableThatShouldBeChecked != null
&& anotherOne != null
&& justAnotherCheckThatIsNeededForTestingNullity != null
&& allTheseChecksAreReallyBoring != null
&& thereSeemsToBeADesignFlawIfSoManyChecksAreNeeded != null)
{
// ToDo: Everything is checked, do something...
}

If you would simply swap all the null words to the beginning you can much easier spot all the checks:

if(null != someVariableThatShouldBeChecked
&& null != anotherOne
&& null != justAnotherCheckThatIsNeededForTestingNullity
&& null != allTheseChecksAreReallyBoring
&& null != thereSeemsToBeADesignFlawIfSoManyChecksAreNeeded)
{
// ToDo: Everything is checked, do something...
}

So this example is maybe a bad example (refer to coding guidelines) but just think about you quick scroll over a complete code file. By simply seeing the pattern

if(null ...

you immediately know what's coming next.

If it would be the other way around, you always have to scan to the end of the line to see the nullity check, just letting you stumble for a second to find out what kind of check is made there. So maybe syntax highlighting may help you, but you are always slower when those keywords are at the end of the line instead of the front.

I don't see any advantage in following this convention. In C, where boolean types don't exist, it's useful to write

if( 5 == variable)

rather than

if (variable == 5)

because if you forget one of the eaqual sign, you end up with

if (variable = 5)

which assigns 5 to variable and always evaluate to true. But in Java, a boolean is a boolean. And with !=, there is no reason at all.

One good advice, though, is to write

if (CONSTANT.equals(myString))

rather than

if (myString.equals(CONSTANT))

because it helps avoiding NullPointerExceptions.

My advice would be to ask for a justification of the rule. If there's none, why follow it? It doesn't help readability

As many pointed out, it is mostly in old C code it was used to identify compilation error, as compiler accepted it as legal

New programming language like java, go are smart enough to capture such compilation errors

One should not use "null != variable" like conditions in code as it very unreadable