Since the release of C# 7.0 in March 2017 there have been numerous ways to check for null. So which should you choose?
In this post, I’ll show you the new (ok, relatively new) way to test for nulls in your code, and provide a few reasons why you should ditch those comfy old slippers that you know and love.
For many years now, the staple way to test for nulls in C# has been:
However, during MS Build’s 2018 keynote talk, Mads Torgersen said “[is null] is how you should be checking for null now that you have pattern matching” (~48m 50s).
He goes on to explain that this is because the == operator can be overridden, therefore using equality operators will not necessarily behave in the way you would expect:
Unlike equality operators, ‘is null’ uses pattern matching to compare your values to null, and this can’t be over ridden by custom code within specific types. ‘is null’ will always compare your argument against null.
Since Mads pointed this out, I’ve have been using ‘is null’ in my code in order to avoid any weird behaviour being introduced by refactoring that might occur in the future. But then I started to think about the inverse check. What if I want to do something specific when my argument isn’t null?
Historically I’d do this:
The inequality operator can be overridden too, so I started playing with alternatives that would avoid these pitfalls without being difficult to read. Eventually, I begrudgingly settled on this:
I wasn’t happy with it, and often found myself reverting back to trusty old != null, warts n’all.
Then I saw this tweet from Jared Parsons:
I started playing with it, and to be honest, didn’t really like it. It felt weird!
On top of that, Rider underlines ‘is object’ with a nasty yellow squiggle, telling me that I should consider a null check instead.
I persevered and have been using ‘is null’ and ‘is object’ for a while now. I’m comfortable with seeing them in my code, to the point where I now point these things out to other in code reviews.
Then the other day I proposed to the team that we should all use this code moving forward: adopt ‘is null’ and ‘is object’ in favour of == and !=. They had similar reactions to me at first…“hmm, looks weird!”.
Then my Tech Lead said, ‘I wonder what performance implications that has?!?’ Great question!
So to answer that I created some benchmarks, using BenchmarkDotNet, and find out.
Coincidently, while I was doing that I spotted this thread on twitter:
The results of the tests confirm what is already summed up in the Tweet above.
‘is null’ and ‘is object’ either performs faster than == and !=, or the same:
Summary
The safest and fastest way to test for nulls in C# 7.0 and above is to use pattern matching with is null and is object.
