C#: Why You Should Prefer the is Keyword Over the == Operator

In the previous blog post you learned about different ways to do a null check. The traditional way is to use the == operator:

if(person == null) { }

Since C# 7, you can use the is keyword to do a null check:

if(person is null) { }

The is keyword has the big advantage that it ignores any operator overloads that are defined on the class of the instance you want to check. When you use the == operator, it could be possible that this operator is overloaded and you get an unexpected result. Let’s look at a simple example.

The following code snippet shows the Main method of a .NET Console app. At the beginning, a person variable of type Person is declared, and it is initialized with null. Then the results of person == null and person is null are written to the Console.

static void Main(string[] args)
  Person person = null;

  Console.WriteLine("Is Person null?");

  Console.WriteLine($"== says: {person == null}");

  Console.WriteLine($"is says: {person is null}");
public class Person

What do you think is the output of the code above?

Obviously, you might think that this is written to the Console:

Is Person null?
== says: True
is says: True

But actually, what you can definitely say from the code above is that person is null definitely returns true, as the person variable actually is null.

But you can’t say whether person == null returns true or false without seeing the content of the Person class. If the Person class overloads the == operator, it can do whatever it wants.

Let’s just create a hacked Person class like below. As you can see, it overloads the == operator and it just returns false:

public class Person
  public static bool operator ==(Person x, Person y)
    return false;
  public static bool operator !=(Person x, Person y)
    return !(x == y);
  public override bool Equals(object obj)
    return base.Equals(obj);

When you run now the Console app, you will see this output:

Is Person null?
== says: False
is says: True

The is keyword is still right, as the person variable is actually null, but the overloaded operator returns a result that you wouldn’t expect.

So, choose wisely in your code. If you want to do a proper null check, the is keyword is the way to go.

Once you get used to it, it starts looking quite nice in your code.

Share this post

Comments (13)

  • Dew Drop – March 20, 2020 (#3158) | Morning Dew Reply

    […] C#: Why You Should Prefer the is Keyword Over the == Operator (Thomas Claudius Huber) […]

    March 20, 2020 at 12:57 pm
  • Henrich Horvath Reply

    > “The is keyword is still right, as the person variable is actually null, but the overloaded operator returns a result that you wouldn’t expect.”

    well if implementation of == somehow differs, then it should be written in documentation, therefore you should expect it ¯\_(ツ)_/¯
    (like for example in Unity)

    Thought it is a problem in case of missing documentation or when users didnt read it.

    March 21, 2020 at 12:55 am
    • Thomas Claudius Huber Reply

      Hey Henrich,

      good point with the documentation. But aren’t nearly all problems a case of missing documentation or a case where users didn’t read it? :-)

      I think the advantage of “is” is that you don’t have to read any docs, you just know what it does.

      March 21, 2020 at 9:29 am
  • Patrice Tremblay Reply

    It’s worth noting that both the null coalescing operator (??) and the null coalescing assignment operator (??=) behave like the is statement, safely ignoring the overridden ‘==’ operator.

    Nice article and thanks for blowing my mind on this Sunday morning ;-).

    March 22, 2020 at 3:11 pm
    • Thomas Claudius Huber Reply

      Hi Patrice,

      yes, that’s correct, Null coalescing operator ?? does always a proper null check, no matter if the == operator is overwritten or not.

      Thanks for the great feedback.

      Have a nice Sunday! :-)

      March 22, 2020 at 3:55 pm
    • Thomas Claudius Huber Reply

      Good note! Thank you Patrice.

      April 18, 2020 at 6:22 pm
  • Ravi Chenna Reply

    != operator is it not overloadable, if it is then you will have the same situation, then is there a ‘is not’ keyword in C# language

    May 8, 2020 at 6:10 pm
    • Ravi K Chenna Reply

      I just figured you could use !(obj is null) but looks ugly compared to (obj != null)

      May 8, 2020 at 6:15 pm
      • Thomas Claudius Huber Reply

        Yes, exactly. !(obj is null) is the way to go. (obj is object) should also work. :)

        May 8, 2020 at 6:42 pm
  • radusun Reply

    Hi Thomas,

    I have just stumbled upon a special case where the compiler seams to be happy with it, but will have the “nice” effect of throwing an error at runtime.
    If T is a reference everything is just fine, but if T is a ValueType then this part will throw an Exception:
    if (default(T) is not null) { … }

    Originally the code looked like:
    if (default(T) != null) { … }
    and this works for all cases.

    January 20, 2022 at 6:31 pm
    • radusun Reply

      I forgot to mention that T is a generic type.

      January 20, 2022 at 6:35 pm
      • Thomas Claudius Huber Reply

        Hi Radusun, yes, that’s a great example where we still need to be careful. :) Thanks for sharing.

        January 24, 2022 at 11:04 am
    • askazakov Reply

      Could you explain a little bit more. I’ve tried

      public static class TClass
      public static string M()
      if (default(T) is not null)
      return “default is not null”;

      return “default is null”;
      and there is no exception

      February 14, 2022 at 7:11 am

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.