The Right Way to Check for Null in C#

And for those wondering, both null-coalescing operators (??= and ??) and the ?. operator will be compiled to the "is null" version if the compiler detects that the operator is overloaded

This does so not make sense when you watch the Code Cop series. In Code Cop you say things like "don't do this all the time, context is important" and here in this video you're all about "do the is null period" even though overloading the operator is a situation you will never encounter. Unless you join a already established project, but then this advice has to be tailored for those cases. Otherwise you will never have that situation, unless you have a project and some nitwit comes over and overrides one of the most used default behaviours... again, very rare.

Why would you ever overload the equals operator? I would argue you shouldnt be doing this and readability of reference equals is worse.

So basically we can override the operator for 'fun' ad then blame c# for doing what it suppose to do.

Now, lets talk about the use cases of the goto statement in C#

Anyone complaining about the verbosity of "is not null" is probably doing something strange anyway. When do you WANT something to be null? The normal way to code defensively is to do a null check warn, tidy and drop out if its null. You can do that with "if (x is null) return;" and the rest is implicitly not null and you save on indentation and compliexity.

hey there! important you mentioned "unity" game engine about nullable things . thanks

You just wasted 10 minutes of our time by overriding == to prove that it could break 😑

Ugh... Now I have a headache and a pile of code to review. Thanks for sharing!

if some one overloads the equals operator on a class in a way, that simple null checks don't work any more, then i chop their hands of.

C# is nightmare

The "is null" syntax makes me think of SQL and that triggers some PTSD.

this btw is why operator overloading is toxic and shouldnt exist. yes its cute for like vector and matrix math, but it would be better just to use functions.

Shouldn't be a issue if your team follow coding standards. In my team code that overrides == operator would never pass code review. If we want custom comparison we add methods and then use that method.

It's irrelevant, under the hood the operation is equivalent. If you're going to get so caught up in pretty syntax, then you have a major psychological problem.

Unsubscribed

I use a naming convention of a "maybe" prefix for my nullable variables. I then use the form: if (maybeValue is not { } value), which usually then is the exceptional case (return an error message or something), and then the normal case can continue on with the known non-null value variable.

Great feature and a great video.
In fact I've actually written about "x is object" back in 2019 in a blog post I've named "The perfect non-null test". In c# 9 when they've added the not keyword it got that much better with "x is not null" - but still learned something new about how it actually works in lower c#, so thanks!

TBH I haven't seen operator override for years now - it's really exotic tool that can be used only in domain objects and you have to have really good reason to override it, where most null checks are performed od DTOs in layers above.

Yeah right. The head cracking problem of programming is enough for me, i don't want more complexity.
In my religion, null is null, saith the Lord!!.
Bruh!!, if anyone tries otherwise on me, you're fired.
Let the poor breatheeeeee.....

Thanks for the vid, it's been a burning question for me lately which way is best.

This is a waste of time, read the comments and then leave.

The correct solution is to remove the badly overriden operator and keep using to correct way of == null. No sane person will change how to check for null in case someone else writtes really bad code

Resharper tries to use this and I don’t like it.

I noticed that in Unity doing `gameObject == null` might also be wrong when trying to check if a game object has been destroyed. I read that the check should be `gameObject == null && gameObject.Equals(null)`. Is this correct and if so what's the difference in the overloading for null vs Equals?

This is a little contrived

1. Operators are not dangerous.
2. Checking with == is perfectly fine.

If you overload == operator then you should have a very good reason to do and you should use it accordingly. I've been programming for more almost 15 years and I don't remember a single case someone overloaded == operator and my null check was broken.

Do not misinform new developers just to get more views.

This is were I differ from your explanation, if something is overridden it should be used.

Calling the equals operator potentially dangerous because of the possibility of it being overriden is bogus.
Might as well go gambling due to the life changing possibility of winning the jackpot

Learn something new from this video. Also, my policy is to never use operator overload and in most companies I worked for operator overload is prohibited.

Recursive pattern, used in 'is {}', is only available from C# 8. Since it's syntactical sugar, you can change the language version in your csproj file without changing the .NET version with `<LangVersion>8.0</LangVersion>`. This worked for my .NET Standards 2 project

C# goes python. The cleanness of the OO language disappears as it follows the current fashion. Also, Microsoft is taking over python, they want to go that direction (AI - cntk was not a big success). I feel c# is getting more and more schizophrenic: first a language (clr) that is all about re-usability refuse to reuse any thirdparty: rewrite them instead (NHibernate - EF core, minimal api, but if you have a rest api code in front of you, I bet you have 2 different json library added to your project). And now these python based features: we need to rethink design patterns, anemic models, etc. The solid OO theoretical background is disappearing. So, if you start a new c# project, you need to decide the style as well. But in the new style it wont beat python or go. Also, because of this 2 different styles, how do you hire a c# dev? I feel c# is obsolete, and for me, the way how microsoft tries to shake it up is not my cup of tea. I could imagine other ways to do that.

If you override operator for equals this way you deserve the problems.

I learned object checking method thanks to resharper. I'm always using is and is not null way. It's more readable for me.

Thanks for pattern matching examples.

Let's be real, if the == operator is overriden in such a way that it can no longer check for null then the correct response is not to adjust your coding style, but to crucify the person wrote the override.

As always an fantastic video! Could you do a video where you explain the different steps how C# code will be compile: Lowered, IL ... etc.? That would be awesome!

I will overload equality operators when I'm not necessarily wanting to resolve whether the reference is the same but rather based on property values, like an object with a DateTime field. I will overload so that the objects are checked for null (via 'is') first then whether the DT field is the same. If they are, the objects are "equal". I do the same for objects that have an ID field as two objects cannot have the same ID without being equal.

So click bait coding videos exist....interesting....

Thanks for mentioning this isn't in Unity

Let the compiler deal with it. Don't turn a null check into computer science. Keep it as simple and clear as possible.

Am I missing something? Why not use is IsNullOrEmpty?

Personally, I avoid using null checks all together, for as long as it is possible.
The idea is that if you need a null check, you are in an invalid state and therefore your code is doing something it shouldn't; the code breaks, allowing you to rethink why it just did, allowing you to find the real cause as to why the data is in said state.
That's not to say that I avoid null checks completely, but rather use them extremely sparingly once I'm sure there is no other way.

I think the real problem is an idiot who would override equals operator to something stupid ;)

Wow! I didn't have a clue about his... Thank you!

Ive been using all these features not because I knew about it but because Resharper always suggested me to change my conditions according to these new ways an di kinda loved it :D