Chapter 2
Null Checks Everywhere!

Identification

Billion-Dollar Mistake

Did you know that the inventor of the concept of null has called it his Billion-Dollar Mistake (https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/)?

As simple as it seems, once you get into larger projects and code bases, you'll inevitably find some code that goes off the deep end in its use of nulls.

Sometimes, we want to simply make a property of an object optional:

class Product{

public id: number;

public title: string;

public description: string;

}

In TypeScript, a string property can be assigned a null value.

But so can a number property!

const chocolate: Product = new Product();

chocolate.id = null;

chocolate.description = null;

Hmmm....

Example

That doesn't look so bad at first glance.

However, it can lead to the possibility of doing something like this:

const chocolate: Product = new Product(null, null, null);

What's wrong with this? Well, it allows your code (in this case, the Product class) to get into an inconsistent state.

Does it ever make sense to have a Product in your system that has no id? Probably not.

Ideally, as soon as you create your Product, it should have an id.

So... what happens in other places that have to deal with logic around dealing with products?

Here's the sad truth:

let title: string;

if(product != null) {

if(product.id != null) {

if(product.title != null) {

title = product.title;

} else {

title = "N/A";

}

} else {

title = "N/A"

}

} else {

title = "N/A"

}

Is that even real code someone would write?

Yes.

Let's look at why this code is unhealthy and considered a code smell before we look at some techniques to fix it.

Is It That Bad?

This code is hard to read and understand. Therefore, it's very prone to bugs when changed.

I think we can agree that having code like this scattered in your app is not ideal – especially when this kind of code is inside important, critical parts of your application!

Non-Nullable Types

As a relevant side note, someone might raise the fact that TypeScript supports non-nullable types (https://www.typescriptlang.org/docs/handbook/advanced-types.html#nullable-types).

This allows you to add a special flag to your compilation options and will prevent, by default, any variables from allowing null as a value.

Let's go over a few points regarding this argument:

• Most of us are dealing with existing code bases that would take tons of work and time to fix these compilation errors.
• Without testing the code well, and carefully avoiding assumptions, we could still potentially cause runtime errors by making these changes.
• This book will teach you about solutions that can be applied to other languages that may not have this option available.

Either way, it's always safer to apply smaller, more targeted improvements to our code. Again, this allows us to make sure the system still behaves the same and avoids introducing a large amount of risk when making these improvements.