For this Monday Links, I’d like to share five reads about interviewing, motivation, and career. These are five articles I found interesting in the past month or two.
Programming Interviews Turn Normal People into A-Holes
This is a good perspective on the hiring process. But from the perspective of someone who was the hiring manager. Two things I like about this one: “Never ask for anything that can be googled,” and “Decide beforehand what questions you will ask because I find that not given any instructions, people will resort to asking trivia or whatever sh*t library they are working on.”
I’ve been in those interviews that feel like an interrogatory. The only thing missing was a table in the middle of a dark room with a two-way mirror. Like in spy movies. Arrrggg!
From this article, a message for bosses: “…(speaking about salaries, dual monitors, ping pong tables) These things are ephemeral, though. If you don’t have him working on the core functionality of your product, with tons of users, and an endless supply of difficult problems, all of the games of ping pong in the world won’t help.”
How to Spot Signs of Burnout Culture Before You Accept a Job
We only have one chance of giving a first impression. Often the first impression we have about one company is the job listing itself. This post shows some clues to read between the lines to detect toxic culture from companies.
I ran from companies with “work under pressure” or “fast pace changing environment” anywhere in the job description. Often that screams: “We don’t know what we’re doing, but we’re already late.” Arrgggg!
I read this one with a bit of skepticism. I was expecting: sprint velocity, planned story points, etc. But I found some interesting metrics, like _five is the number of comments on a document before turning it into a meeting” and “one is the number of times to reverse a resignation.”
Voilà! Another Monday Links. Have you ever found those interrogatories? Sorry, I meant interviews. Do your company track sprint velocity and story points? What metrics do they track instead? Until next Monday Links.
So far in this series about NullReferenceException, we have used nullable operators and C# 8.0 Nullable References to avoid null and learned about the Option type as an alternative to null. Let’s see how to design our classes to avoid null when representing optional values.
Instead of writing a large class with methods that expect some nullable properties to be not null at some point, we’re better off using separate classes to avoid dealing with null and getting NullReferenceException.
Multiple state in the same object
Often we keep all possible combinations of properties of an object in a single class.
For example, on an e-commerce site, we create a User class with a name, password, and credit card. But since we don’t need the credit card details to create new users, we declare the CreditCard property as nullable.
Let’s write a class to represent either regular or premium users. We should only store credit card details for premium users to charge a monthly subscription.
publicrecordUser(Emailemail,SaltedPasswordpassword){publicCreditCard?CreditCard{get;internalset;}// ^^^// Only for Premium users. We declare it nullablepublicvoidBecomePremium(CreditCardcreditCard){// Imagine we sent an email and validate credit card// details, etc//// Beep, beep, boop}publicvoidChargeMonthlySubscription(){// CreditCard might be null here.//// Nothing is preventing us from calling it// for regular usersCreditCard.Pay();// ^^^^^// Boooom, NullReferenceException}}
Notice that the CreditCard property only has value for premium users. We expect it to be null for regular users. And nothing is preventing us from calling ChargeMonthlySubscription() with regular users (when CreditCard is null). We have a potential source of NullReferenceException.
We ended up with a class with nullable properties and methods that only should be called when some of those properties aren’t null.
Inside ChargeMonthlySubscription(), we could add some null checks before using the CreditCard property. But, if we have other methods that need other properties not to be null, our code will get bloated with null checks all over the place.
Instead of checking for null inside ChargeMonthlySubscription(), let’s create two separate classes to represent regular and premiums users.
publicrecordRegularUser(EmailEmail,SaltedPasswordPassword){// No nullable CreditCard anymorepublicPremiumUserBecomePremium(CreditCardcreditCard){// Imagine we sent an email and validate credit card// details, etcreturnnewPremiumUser(Email,Password,CreditCard);}}publicrecordPremiumUser(EmailEmail,SaltedPasswordPassword,CreditCardCreditCard){// Do stuff of Premium Users...publicvoidChargeMonthlySubscription(){// CreditCard is not null here.CreditCard.Pay();}}
Notice we wrote two separate classes: RegularUser and PremiumUser. We don’t have methods that should be called only when some optional properties have value. And we don’t need to check for null anymore. For premium users, we’re sure we have their credit card details. We eliminated a possible source of NullReferenceException.
We’re better off writing separate classes than writing a single large class with nullable properties that only have values at some point.
I learned about this technique after reading Domain Model Made Functional. The book uses the mantra: “Make illegal state unrepresentable.” In our example, the illegal state is the CreditCard being null for regular users. We made it unrepresentable by writing two classes.
Voilà! This is another technique to prevent null and NullReferenceException by avoiding classes that only use some optional state at some point of the object lifecycle. We should split all possible combinations of the optional state into separate classes. Put separate state in separate objects.
If you want to practice the techniques and principles from this series with interactive coding listings and exercises, check my course Mastering NullReferenceException Prevention in C# on Educative. It covers all you need to know to prevent this exception in the first place.
In the previous post of this series, we covered three C# operators to simplify null checks and C# 8.0 Nullable References to signal when things can be null. In this post, let’s learn a more “functional” approach to removing null and how to use it to avoid null when working with LINQ XOrDefault methods.
1. Use Option: A More Functional Approach to Nulls
Functional languages like F# or Haskell use a different approach for null and optional values. Instead of null, they use an Option or Maybe type.
With the Option type, we have a “box” that might have a value or not. It’s the same concept of nullable ints, for example. I bet you have already used them. Let’s see an example,
int?maybeAnInt=null;varhasValue=maybeAnInt.HasValue;// falsevardangerousInt=maybeAnInt.Value;// ^^^^^// Nullable object must have a value.varsafeInt=maybeAnInt.GetValueOrDefault();// 0
With nullable ints, we have variable that either holds an interger or null. They have the HasValue and Value properties, and the GetValueOrDefault() method to access their inner value.
We can extend the concept of a box with possibly a value to reference types with the Option type. We can wrap our reference types like Option<int> or Option<Movie>.
We created two optional ints: someInt and none. Then, we used Map() to double their values. Then, to retrieve the value of each optional, we used ValueOr() with a default value.
For someInt, Map() returned another optional with the double of 42 and ValueOr() returned the same result. And for none, Map() returned None and ValueOr() returned -1.
How to Flatten Nested Options
Now, let’s rewrite the HttpContext example from previous posts,
Notice that instead of appending ? to type declarations like what we did with in the past post when we covered C# 8.0 Nullable References, we wrapped them around Option.
This time, Current is a box with Request as another box inside. And Request has the ApplicationPath as another box.
Now, let’s retrieve the ApplicationPath,
varpath=HttpContext.Current.FlatMap(current=>current.Request)// ^^^^^.FlatMap(request=>request.ApplicationPath)// ^^^^^.ValueOr("/some-default-path-here");// ^^^^// Or//.Match((path) => path , () => "/some-default-path-here");// This isn't the real HttpContext class...// We're writing some dummy declarations to prove a pointpublicclassHttpContext{publicstaticOption<HttpContext>Current;publicHttpContext(){}publicOption<Request>Request{get;set;}}publicrecordRequest(Option<string>ApplicationPath);
To get the ApplicationPath value, we had to open all boxes that contain it. For that, we used the FlatMap() method. It grabs the value in the box, transforms it, and returns another box. With FlatMap(), we can flatten two nested boxes.
Option's FlatMap to flatten nested options
Notice we didn’t do any transformation with FlatMap(). We only retrieved the inner value of Option, which was already another Option.
This is how we read ApplicationPath:
With FlatMap(), we opened the Current box and grabbed the Request box in it.
Then, we used FlatMap() again to open Request and grab the ApplicationPath.
Finally, with ValueOr(), we took out the value inside ApplicationPath if it had any. Otherwise, if the ApplicationPath was empty, it returned a default value of our choice.
“This is the way!” Sorry, this is the “functional” way! We can think of nullable ints like ints being wrapped around a Nullable box with more compact syntax and some helper methods.
2. Option and LINQ XOrDefault methods
Another source of NullReferenceException is when we don’t check the result of the FirstOrDefault, LastOrDefault, and SingleOrDefault methods. These methods return null when the source collection has reference types, and there are no matching elements. In fact, this is one of the most common mistakes when working with LINQ.
There are some alternatives to prevent the NullReferenceException when working with XOrDefault methods.
But, let’s combine the XOrDefault methods with the Option type. We can make the XOrDefault methods return an Option<T> instead of null.
The Optional library has FirstOrNone(), LastOrNone() and SingleOrNone() instead of the usual XOrDefault methods.
This time, let’s use FirstOrNone() instead of FirstOrDefault(),
usingOptional.Collections;// ^^^^^varmovies=newList<Movie>{newMovie("Shrek",2001,3.95f),newMovie("Inside Out",2015,4.1f),newMovie("Ratatouille",2007,4f),newMovie("Toy Story",1995,4.1f),newMovie("Cloudy with a Chance of Meatballs",2009,3.75f)};vartheBestOfAll=newMovie("My Neighbor Totoro",1988,5);// With .NET FirstOrDefault()vartheBest=movies.FirstOrDefault(movie=>movie.Rating==5.0,theBestOfAll);// ^^^^^// With Optional's FirstOrNone()vartheBestAgain=movies.FirstOrNone(movie=>movie.Rating==5.0)// ^^^^^.ValueOr(theBestOfAll);// ^^^^^Console.WriteLine(theBestAgain.Name);recordMovie(stringName,intReleaseYear,floatRating);
By using the XOrNone methods, we’re forced to check if they return something before trying to use their result.
Voilà! That’s the functional way of doing null, with the Option or Maybe type. Here we used the Optional library, but there’s also another library I like: Optuple. It uses the tuple (bool HasValue, T Value) to represent the Some and None subtypes.
Even though we used a library to bring the Option type, we can implement our own Option type and its methods. It’s not that difficult. We need an abstract class with two child classes and a couple of extension methods to make it work.
In the previous post of this series, we covered two ideas to avoid the NullReferenceException: we should check for null before accessing the members of an object and check the input parameters of our methods.
Let’s see some new C# operators to simplify null checking and a new feature to better signal possible null references.
1. C# Nullable Operators
C# has introduced new operators to simplify our null checks: ?., ??, and ??=. These operators don’t prevent us from having null in the first place, but they help us to easily write our null checks.
Without Nullable Operators
Let’s start with an example and refactor it to use these new operators.
If you have worked with the old ASP.NET framework, you might have done something like that. If not, don’t worry. We’re only accessing a property down in a property chain, but any of those properties could be null.
Notice that to defend against null, we checked if every property was null to “fail fast” and use a default value.
With Nullable Operators
Now, let’s use the new nullable operators instead,
With the null-conditional operator (?.), we access the property or method of an object only if the object isn’t null. Otherwise, the entire expression evaluates to null. For our example, we retrieve ApplicationPath only if Request isn’t null and Current isn’t null, and HttpContext isn’t null.
Then, with the null-coalescing operator (??), we evaluate an alternative expression if the one on the left of the ?? operator isn’t null. For our example, if any of the properties in the chain to retrieve ApplicationPath is null, the whole expression is null, and the path variable gets assigned to the default string.
With the null-coalescing assignment operator (??=), we assign a new value to a variable only if it’s null. We could also write our example like this,
varpath=HttpContext.Current?.Request?.ApplicationPath;path??="/some-default-path-here";// ^^^^//// The same as//if (path == null)//{// path = "/some-default-path-here"; //}
Notice how we refactored our original example to only two lines of code with these three new operators. Again we could still have null values. These nullable operators make our lives easier by simplifying our null checks.
To solve the NullReferenceException, we should check for null. We got that! But the thing is knowing when we should do it or not. That’s precisely what C# 8.0 solves with Nullable References.
With C# 8.0, all reference variables are non-nullable by default. Accessing the member of nullable references results in compiler warnings or errors.
This is a breaking change. Therefore we need to turn on this feature at the project level in our csproj files. Like these,
<ProjectSdk="Microsoft.NET.Sdk"><PropertyGroup><OutputType>Exe</OutputType><TargetFramework>net6.0</TargetFramework><!-- ^^^^^^ --><!-- We could use netcoreapp3.1|net5.0|net6.0|.net7.0 too --><ImplicitUsings>enable</ImplicitUsings><Nullable>enable</Nullable><!-- ^^^^^^ --><!-- We could use enable|disable|warning too --><WarningsAsErrors>nullable</WarningsAsErrors><!-- ^^^^^^^^ --><!-- We can take the extreme route --></PropertyGroup></Project>
To use Nullable References, we need to target .NET Core 3 and upward. And inside the Nullable node in our csproj files, we could use: enable, disable, or warning. Even, we can take the extreme route and consider all nullable warnings as compilation errors.
With Nullable References On
Let’s see what our motivating example looks like with Nullable References turned on,
stringpath=null;// ^^^^// CS8600: Converting null literal or possible null value to non-nullable typeif(HttpContext.Current==null||HttpContext.Current.Request==null||HttpContext.Current.Request.ApplicationPath==null){path="/some-default-path-here";}else{path=HttpContext.Current.Request.ApplicationPath;}// This isn't the real HttpContext class...// We're writing some dummy declarations to prove a pointpublicclassHttpContext{publicstaticHttpContextCurrent;// ^^^^^^^^// CS8618: Non-nullable field 'Current' must contain// a non-nullable value when exiting constructorpublicHttpContext()// ^^^^^^^^^^^// CS8618: Non-nullable field 'Current' must contain// a non-nullable value when exiting constructor{}publicRequestRequest{get;set;}}publicrecordRequest(stringApplicationPath);
Notice we have a warning when initializing path to null. And another one in the declaration of our HttpContext class if we don’t initialize any non-nullable fields. That’s not the real HttpContext by the way but bear with me. Also, we don’t need to check for null when retrieving the ApplicationPath since all our references aren’t nullable by definition.
To declare a variable that can be null, we need to add to its type declaration a ?. In the same way, we have always declared nullable primitive types like int?.
Without Null Checks
Let’s change our example to have nullable references and no null checks,
// Notice the ? symbol here// vvvstring?path=HttpContext.Current.Request.ApplicationPath;// ^^^^^^^^^^^// CS8602: Deference of a possibly null value// This isn't the real HttpContext class...// We're writing some dummy declarations to prove a pointpublicclassHttpContext{publicstaticHttpContext?Current;// ^^^// Notice the ? symbol herepublicHttpContext()// ^^^// No more warnings here{}publicRequestRequest{get;set;}}publicrecordRequest(string?ApplicationPath);
Notice this time, when declaring the variable path, we have a warning because we’re accessing the Current property, which might be null. Also, notice we changed, inside the HttpContext class, the Current property to have the HttpContext? type (with a ? at the end of the type).
Now with Nullable References, we have a way of telling when we should check for null by looking at the signature of our methods.
Voilà! Those are the new C# operators to simplify our null checks. We said “new” operators, but we have had them since C# 6.0. And that’s how we can tell if our references can be null or not using Nullable References.
We have these nullable operators available even if we’re using the old .NET Framework. But, to use Nullable References, we should upgrade at least to .NET Core 3.0.
This exception doesn’t need an introduction. I bet you already have found the exception message: “Object reference not set to an instance of an object.” In this series of posts, let’s see some techniques to completely eliminate the NullReferenceException from our code. In this post, let’s see when NullReferenceException is thrown and a strategy to fix it.
NullReferenceException is thrown when we access a property or method of an uninitialized variable of a reference type. The easier way to solve this exception is to check for null before accessing the members of an object. But C# has introduced new operators and features to avoid this exception.
Let’s write an example that throws NullReferenceException,
varmovie=FindMovie();Console.Write(movie.Name);// ^^^^^// System.NullReferenceException: 'Object reference not set to an instance of an object.'//// movie was null.Console.ReadKey();staticMovieFindMovie(){// Imagine this is a database call that might// or might not return a moviereturnnull;// ^^^^}recordMovie(stringName,intReleaseYear,floatRating);
Notice we returned null from FindMovie(). That caused the NullReferenceException. But, it could be a method that accessed a database and didn’t find anything or an API controller method that didn’t receive a required input parameter.
In our last example, we got a NullReferenceException when we returned null from a method. But, we could also find this exception when we try to loop through a null list or array, for example.
Speaking of returning null, one way to prevent the NullReferenceException is to never pass null between objects. Instead of returning null, let’s use empty lists and strings, or the Null Object pattern. And let’s use intention-revealing defaults for that.
To fix the NullReferenceException, we might be tempted to write a try/catch block around the code that throws it. But, let’s not catch the NullReferenceException.
Let me say that again: don’t throw or catch NullReferenceException.
By any means, please, let’s not write something like this,
try{AMethodThatMightThrowNullReferenceException();}catch(NullReferenceException){// ...// Beep, beep, boop// Doing something with the exception here}
A NullReferenceException is a symptom of an unhandled and unexpected scenario in our code, and catching it won’t handle that. A NullReferenceException is a developer’s mistake.
2. Check for null
The solution for the NullReferenceException is to check for nulls and defense against them.
Let’s fix our previous example by adding a null check. Like this,
varmovie=FindMovie();if(movie!=null)// ^^^^^{// We're safe here...//// No more System.NullReferenceException// at least due to a movie being null Console.Write(movie.Name);}Console.ReadKey();staticMovieFindMovie(){// Imagine this is a database call that might// or might not return a moviereturnnull;// ^^^^}recordMovie(stringName,intReleaseYear,floatRating);
Notice we checked if the movie variable wasn’t null. As simple as that.
Alternatives to check for null
The lack of options isn’t an excuse to not check for null. Since some recent C# versions, and thanks to pattern matching, we have a couple of new ways to check for null. We can use any of these:
if (movie != null) { //... },
if (movie is not null) { //... },
if (movie is { }) { //... }, and,
if (movie is object) { //... }
Some of those don’t look like C# anymore. I still prefer the old if (movie != null) .... Which one do you prefer?
3. Defense against null
If the solution to NullReferenceException were to simply check for null, that wouldn’t be the Billion-Dollar mistake. And I wouldn’t be writing this series. But the thing is knowing when a reference might be null or not and, therefore, when we should check for it. That’s when we should protect ourselves against null.
To protect against null, inside our methods, let’s check our input parameters and throw a more detailed exception. C# has an exception for missing parameters: ArgumentNullException.
The ArgumentNullException stack trace contains the name of the parameter that was null. That will help us to better troubleshoot our code. Often, the NullReferenceException stack trace doesn’t include what was null in the first place. Happy debugging time!
Let’s check our input parameters,
publicvoidDoSomething(Moviemovie){if(movie==null){thrownewArgumentNullException(nameof(movie))}// Since C# 10, we can also write:// ArgumentNullException.ThrowIfNull(movie);// Beep, beep, boop// Doing something here...}
Notice that instead of waiting for NullReferenceException, we proactively prevented it by checking for a required parameter and throwing a controlled ArgumentNullException.
Voilà! That’s the NullReferenceException and how to fix it by checking for null. Remember, we shouldn’t catch this exception but prevent and prepare for it.
