Enroll video course *Beginning Object-Oriented Programming with C#* ► codinghelmet.com/go/beginning-oop-with-csharp Download the source code: www.patreon.com/posts/source-code-for-91519903 Learn from related videos: How to Avoid Null Reference Exceptions: Optional Objects in C# ► th-cam.com/video/8-2xr_kBRnQ/w-d-xo.html Build Your Own Option Type in C# and Use It Like a Pro ► th-cam.com/video/gpOQl2q0PTU/w-d-xo.html Avoid Returning Null From Methods - There Is a Better Way To Write Them! ► th-cam.com/video/HRLdcMil7Ec/w-d-xo.html
Great video, you have talent to clearly explain things. @20:00 IMHO .Do is unfortunately named, should be named DoIfExists or something in this regard.
I agree with the name, though. I think that the else branch should be forgotten when thinking about optional objects. Anyway, that is just an opinion. Hard to prove right either way...
@@zoran-horvat Should but if you new to codebase or Option it could lead to some confusion, redirecting away from thought about "hidden" negative path. But maybe i'm to picky :D
@@zoran-horvat I beg to differ. For years I worked in languages that didn't support them, so we had to use sentinel or magic values to determine when data is not available or otherwise hasn't been set yet. That's a much bigger nightmare. Moving to tools which added null functionality improved that drastically! The concept of a null is so powerful!!! And made working with data and ensuring that I'm working with the right data so much easier! And the concept isn't even hard to grasp. One example... you have a method to query a database for user by ID... and go to retrieve user 123, but user ID 123 doesn't exist in the database, for whatever reason. Having that method intentionally return a null tells the calling code that there is no user 123; it doesn't exist. The other techniques I see used, either to throw an exception, or instantiate a blank "fake" user to avoid the null are both terrible ideas -- exceptions are slow and are intended to be "exceptional" when unpredictable things happen, and creating a blank object... well, you're working with data that isn't real and the calling code has to check for that too. Result objects don't solve this problem, because the database query actually is successful -- there is just no result that matches the specified criteria. A simple null return makes it all very easy without wasting any resources. And the Optional technique introduces a lot of extra boilerplate code that just isn't necessary. Most of the time when I see developers struggling with null exceptions, it's because they are trying to process data that they haven't initialized yet. So that exception is incredibly useful! It tells them that, hey, you forgot to do something somewhere else in your code. The current C# nullable reference type behavior encourages the practice of new()ing objects just to make the warnings go away or letting C# instantiate default objects for you that don't represent real data... so the code that would have thrown an exception using the "old" way if nulls were embraced, no longer throws those exceptions. So while, yes, it avoids the exception, that code is now working with fake data, and because no error is thrown, the developer isn't made aware of it. It happily proceeds down the happy path as if everything is perfect when it really isn't. This is a bigger problem than just fixing the exception. Exceptions tell you that you did something wrong and it needs to be addressed. But with the other technique, the code isn't even aware that there is a problem. When you do discover it, you have to backtrace to see where your object reference was assigned incorrectly. Very frustrating and time consuming. I'll take an exception over that every time. Many techniques for avoid nulls also abstract away the concept that reference-type objects are actually pointers and memory has to be allocated and CPU cycles are used to create that an object any time you instantiate or even declare one that isn't nullable. It makes developers much more careless about using those resources. And causes a lot of confusion about how reference types actually work. The majority of developers that I know that actually like C#'s nullable reference feature, I promise you, don't understand how objects actually work, and that modifying the contents of an object passed to a method actually modify the original object. The whole concept (and benefits) of reference objects is lost on them. And I believe that leads to more bugs than just taking the time to learn to work with nulls in the first place. I'd even go so far to say that anyone who doesn't like nulls, or doesn't understand nulls, shouldn't be using reference types at all, because if a null seems like an inconvenience, they don't get why objects can be so useful and so powerful. Structs are probably better for developers at that skill level. Techniques like what you show in this video make it much more difficult to determine whether you have required data missing, or if the data is actually an empty value. There is a big difference between the two, and hiding that for the sake of avoiding a few null checks and useful exceptions is kind of sad. Because of the null coalescing and the null conditional operator, dealing with nulls is really easy. The stuff you're doing in this and other videos is a lot more work than just learning how to use nulls properly in the first place. The code is longer, more complicated, and harder to read than anything I write which fully embraces the concept of a null.
Change warnings to errors in csproj. Then you are forced to use the techniques you present? This was a really good video! Thank you for supporting null (now)
Some teams turn nullable warnings to errors. Other teams say if we did that, we would have a thousand build errors. Still, most teams struggle with nullable warnings for the trivial reason that their projects include code that is ages old, and they simply cannot clean it realistically under any circumstances. And so they live with the warnings and try to not make them worse.
@@zoran-horvat I am in that situation, I also try to clean up these warning when I work on code that includes these warnings. Piece by piece making the code better.
Enroll video course *Beginning Object-Oriented Programming with C#* ► codinghelmet.com/go/beginning-oop-with-csharp
Download the source code: www.patreon.com/posts/source-code-for-91519903
Learn from related videos:
How to Avoid Null Reference Exceptions: Optional Objects in C# ► th-cam.com/video/8-2xr_kBRnQ/w-d-xo.html
Build Your Own Option Type in C# and Use It Like a Pro ► th-cam.com/video/gpOQl2q0PTU/w-d-xo.html
Avoid Returning Null From Methods - There Is a Better Way To Write Them! ► th-cam.com/video/HRLdcMil7Ec/w-d-xo.html
Awesome video. There is a difference between "developing a feature" and "developing a feature with the mindset of preventing bugs"
Indeed!
Zoran you are always a contribution greetings from Chile
🍺🥃🍻🥃🍺 Ziveli Zoki legendo!
Very nice presentation. Beautifully structured. Thank you!
Didn't know "ShowCase" is a synonyms of display
Great video, you have talent to clearly explain things.
@20:00 IMHO .Do is unfortunately named, should be named DoIfExists or something in this regard.
I agree with the name, though. I think that the else branch should be forgotten when thinking about optional objects.
Anyway, that is just an opinion. Hard to prove right either way...
@@zoran-horvat Should but if you new to codebase or Option it could lead to some confusion, redirecting away from thought about "hidden" negative path. But maybe i'm to picky :D
I still don't understand the paranoia and aversion to nulls. They are incredibly useful, and not that hard to work with!
They are not incredibly useful. Start from that point.
@@zoran-horvat I beg to differ. For years I worked in languages that didn't support them, so we had to use sentinel or magic values to determine when data is not available or otherwise hasn't been set yet. That's a much bigger nightmare. Moving to tools which added null functionality improved that drastically! The concept of a null is so powerful!!! And made working with data and ensuring that I'm working with the right data so much easier! And the concept isn't even hard to grasp.
One example... you have a method to query a database for user by ID... and go to retrieve user 123, but user ID 123 doesn't exist in the database, for whatever reason. Having that method intentionally return a null tells the calling code that there is no user 123; it doesn't exist. The other techniques I see used, either to throw an exception, or instantiate a blank "fake" user to avoid the null are both terrible ideas -- exceptions are slow and are intended to be "exceptional" when unpredictable things happen, and creating a blank object... well, you're working with data that isn't real and the calling code has to check for that too. Result objects don't solve this problem, because the database query actually is successful -- there is just no result that matches the specified criteria. A simple null return makes it all very easy without wasting any resources. And the Optional technique introduces a lot of extra boilerplate code that just isn't necessary.
Most of the time when I see developers struggling with null exceptions, it's because they are trying to process data that they haven't initialized yet. So that exception is incredibly useful! It tells them that, hey, you forgot to do something somewhere else in your code.
The current C# nullable reference type behavior encourages the practice of new()ing objects just to make the warnings go away or letting C# instantiate default objects for you that don't represent real data... so the code that would have thrown an exception using the "old" way if nulls were embraced, no longer throws those exceptions. So while, yes, it avoids the exception, that code is now working with fake data, and because no error is thrown, the developer isn't made aware of it. It happily proceeds down the happy path as if everything is perfect when it really isn't. This is a bigger problem than just fixing the exception. Exceptions tell you that you did something wrong and it needs to be addressed. But with the other technique, the code isn't even aware that there is a problem. When you do discover it, you have to backtrace to see where your object reference was assigned incorrectly. Very frustrating and time consuming. I'll take an exception over that every time.
Many techniques for avoid nulls also abstract away the concept that reference-type objects are actually pointers and memory has to be allocated and CPU cycles are used to create that an object any time you instantiate or even declare one that isn't nullable. It makes developers much more careless about using those resources. And causes a lot of confusion about how reference types actually work. The majority of developers that I know that actually like C#'s nullable reference feature, I promise you, don't understand how objects actually work, and that modifying the contents of an object passed to a method actually modify the original object. The whole concept (and benefits) of reference objects is lost on them. And I believe that leads to more bugs than just taking the time to learn to work with nulls in the first place.
I'd even go so far to say that anyone who doesn't like nulls, or doesn't understand nulls, shouldn't be using reference types at all, because if a null seems like an inconvenience, they don't get why objects can be so useful and so powerful. Structs are probably better for developers at that skill level.
Techniques like what you show in this video make it much more difficult to determine whether you have required data missing, or if the data is actually an empty value. There is a big difference between the two, and hiding that for the sake of avoiding a few null checks and useful exceptions is kind of sad.
Because of the null coalescing and the null conditional operator, dealing with nulls is really easy. The stuff you're doing in this and other videos is a lot more work than just learning how to use nulls properly in the first place. The code is longer, more complicated, and harder to read than anything I write which fully embraces the concept of a null.
Change warnings to errors in csproj. Then you are forced to use the techniques you present?
This was a really good video! Thank you for supporting null (now)
Some teams turn nullable warnings to errors. Other teams say if we did that, we would have a thousand build errors.
Still, most teams struggle with nullable warnings for the trivial reason that their projects include code that is ages old, and they simply cannot clean it realistically under any circumstances.
And so they live with the warnings and try to not make them worse.
@@zoran-horvat I am in that situation, I also try to clean up these warning when I work on code that includes these warnings. Piece by piece making the code better.
❤❤❤❤❤🎉🎉🎉🎉🎉🎉