Using "is object" instead of "!= null" or Object.ReferenceEquals() [closed]

Question

It has always bothered me that C# doesn't have a dedicated reference equality operator, one that can't be overloaded. To test if a reference is null, I want to write code like this:

if (thing == null)

But there's always this nagging thought, "What if the class has overloaded the == operator?". I'm not interested in whether the class considers the object equivalent to null. I'm interested in whether the object reference is null. The alternatives seem to be casting to object:

if ((object)thing == null)

and Object.ReferenceEquals():

if (Object.ReferenceEquals(thing, null)) // long form
if (ReferenceEquals(thing, null)) // short form

But recently I have been writing code like this:

if (thing is object) // thing != null
if (!(thing is object)) // thing == null

I read this as "if thing is an object", which is to say that it's set to an object. I realize this isn't the purpose of the "is" operator, but it does check for null references and all reference types inherit from object, so... why not?

I found that, to me at least, code like this is more readable and much more comfortable to type, especially since the affirmative case (thing is object) is much more common in my code than the negative case (!(thing is object)).

So my question is, are there any pitfalls or edge cases that I'm not aware of? Is it considered bad practice or inefficient? Is it confusing? Why don't I ever see code like this?

Answer 1

With

if (thing is object)
  ...

you obfuscate what you want to do - check for null. It might be obvious and clean to you at the moment, but it might not be in a few month (given you've dropped that practice) and it's certainly not obvious for anyone else. If I encountered this, it'd leave me puzzled about the intention of the author. And if you need a comment to explain what you do ... don't do it. (Of course there are situations where you can and should, but definitely not for something as simple as a null-check.)

Eventually you will render your code less maintainable, since understanding your code will always need a double take. Do yourself a favour and keep your code as clean as possible and this means being honest about your intentions.