Should null be checked on the left or right hand side

Question

In reviewing some code, I have seen:

if (null == condition) { ... }

and I've also seen:

if (condition == null) { ... }

I seem to remember that there's an advantage to having null on the left hand side, but I can't remember it and was thinking that it's an older runtime item that's been optimized away with newer .NET runtimes. I tend to use the latter null check, so the former one catches my eye.

So is this a matter of style, or is there an advantage to having null be on the left or right hand side of an evaluation?

Answer 1

The classic reason in C-style languages is to protect against mis-typing the equality == as assignment =. You can't assign to a constant - i.e. the following is illegal and hence the compiler will catch the bug:

if (false = condition) { ... }

whereas this is totally legal (but probably not what the author intended:

if (condition = false) { ... }

Note: This problem is limited in C# (compared to say vanilla C) as if statements require a bool (as noted in the comments below), so the only case this actually causes problems is if your type is a bool.

Answer 2

It can make a difference in three cases.

One is where the typo of condition = null is valid in an if. This is more common in C-style languages that would allow null in an if (valued as false), which is most of them, but not C#.

It is possible to create a type that has this effect in C#:

public class Test
{
  public static bool operator true(Test x)
  {
    return true;
  }
  public static bool operator false(Test x)
  {
    return false;
  }
}
void Main()
{
  Test test = new test();
  if (test = null)
  {
    Console.WriteLine("!");
  }
}

There's not a lot of times that overloading these operators make sense, especially since .Net 2.0 introduced generics (it had more value for types like SqlBoolean that enabled a value to indicate true, false or null in the way we'd now use bool?).

So this case is pretty marginal in C#.

Another is similar, if there's an implicit conversion to bool or to a type that in turn implements the true and false operators:

void Main()
{
  Test test = new Test();
  if (test = null)
  {
    Console.WriteLine("!");
  }
}
public class Test
{
  public static implicit operator bool(Test x)
  {
    return true;
  }
}

Implicit operators are worth avoiding for a few reasons, but this is slightly more likely than the first example, though still nowhere near to being common.

Yet another is if == is overloaded in a non-symmetric manner:

public class Test
{
  public static bool operator == (Test x, Test y)
  {
    return ReferenceEquals(x, null);
  }
  public static bool operator !=(Test x, Test y)
  {
    return !(x == y);
  }
}
void Main()
{
  Test test = new Test();
  if (test == null)
  {
    Console.WriteLine("This won't print.");
  }
  if (null == test)
  {
    Console.WriteLine("This will print.");
  }
}

But since a non-symmetric == is always a bug, then this depends upon a bug in the operator to have any effect. This probably happens slightly more often than the first case, but it should be fixed when it does, so it's of even less real concern.

So while it can have an effect in C# the cases are rare and mostly based on someone else having done something they shouldn't.

As such, its mainly a matter of style. People who put the null first tend to have picked it up from languages where it makes more of a difference.

Answer 3

Regardless of how (null == condition) compiles, using an exemplary value like null as the first (left) operand is counter-intuitive. Instead, the first operand should suggest what you intend to evaluate.