Why null is an abomination
Tags: javascript, programming, typescript
Published: 2024-04-10 17:57:24

Imagine you're halfway through your third cup of coffee, navigating through a sea of `null` in your codebase, and you can't help but whisper to yourself, "What in the world..." Perhaps you're even tempted to unleash a fiery comment into the void of the internet. It’s widely known that Tony Hoare, the architect behind the null reference back in 1965, has famously labeled it his "billion-dollar blunder."

![Humorous GIF depicting frustration with null references](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d0d4o6l3s45iglehbqg5.gif)

Let’s dive into the intricacies of `null` through the lens of TypeScript, a language that you all know (and hate?).

## Unraveling the Mystery of `null`

At its core, `null` signifies the intentional absence of a value. Its sibling, `undefined`, serves a similar role, denoting an uninitialized state. Here’s a simple breakdown:
- `undefined`: A variable not yet blessed with a value.
- `null`: A conscious decision to embrace emptiness.

Consider this example:
```ts
type User = {
  username: string,
  pictureUrl?: string,
};

type UpdateUser = {
  username?: string,
  pictureUrl?: string | null,
};

const update = (user: User, data: UpdateUser) => {
  if (data.pictureUrl === undefined) {
    // No action required
    return;
  }
  if (typeof data.pictureUrl === "string") {
    // Update in progress
    user.pictureUrl = data.pictureUrl;
  }
  if (data.pictureUrl === null) {
    // Time to say goodbye
    delete user.pictureUrl;
  }
}
```

This scenario is common when working with partial objects from APIs, where `undefined` fields imply no change, and `null` explicitly requests data deletion.

However, how clear is it that `null` means "I am going to delete something"? You better hope that you have a big warning banner in your documentation and that your client will never 	inadvertently send a `null` value by mistake (which is going to happen by the way).

It feels natural because you have "NULL" in your database but employing `null` in your programming language solely because it exists in formats like JSON or SQL isn’t a strong argument. After all, a direct one-to-one correspondence between data structures isn't always practical or necessary. Just think about `Date`.

## The trouble with `null`

The introduction of `null` into programming languages has certainly stirred the pot, blurring the lines between absence and presence. This ambiguity, as demonstrated earlier, can lead to unintuitive code. In fact, [the TypeScript team has prohibited the use of `null` within their internal codebase](https://github.com/microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined), advocating for clearer expressions of value absence.

Moreover, the assumption that `null` and `undefined` are interchangeable in JavaScript leads to bewildering behavior, as illustrated by the following examples:
```ts
console.log(undefined == null); // Curiously true
console.log(undefined === null); // Definitely false
console.log(typeof null); // Unexpectedly "object"
console.log(typeof undefined); // As expected, "undefined"
console.log(JSON.stringify(null)); // Returns "null"
console.log(JSON.stringify(undefined)); // Vanishes into thin air
```

Regrettably, I've written code like this more often than I'd like to admit:
```ts
function isObject(value: unknown): value is Record<string, unknown> {
  return typeof value === "object" && value !== null;
}
```

Furthermore, if you begin incorporating both `null` and `undefined` into your codebase, you will likely encounter patterns like the following:
```ts
const addOne = (n: number | null) => (n ? n + 1 : null);

const subtractOne = (n?: number) => (n ? n - 1 : undefined);

const calculate = () => {
  addOne(subtractOne(addOne(subtractOne(0) ?? null) ?? undefined) ?? null);
};
``` 

## The undefined conundrum

Okay, so we just ban `null` from our codebase and only use `undefined` instead. Problem solved, right?

It’s easy to assume that optional properties `{key?: string}` are synonymous with `{key: string | undefined}`, but they’re distinct, and failing to recognize this can lead to headaches.
```ts
const displayName = (data: { name?: string }) =>
  console.log("name" in data ? data.name : "Missing name");

displayName({}); // Displays "Missing name"
displayName({ name: undefined }); // Displays undefined
displayName({ name: "Hello" }); // Greets you with "Hello"
```

Yet, in other scenarios such as JSON conversion, these distinctions often evaporate, revealing a nuanced dance between presence and absence.

```ts
console.log(JSON.stringify({})); // {}
console.log(JSON.stringify({ name: undefined })); // {}
console.log(JSON.stringify({ name: null })); // {"name": null}
console.log(JSON.stringify({ name: "Bob" })); // {"name":"Bob"}
```

So, sometimes there are differences, sometimes not. You just have to be careful I guess!

Another problem of `undefined`, is that you often end up doing useless `if` statements because of them. Does this ring a bell?

```ts
type User = { name?: string };

const validateUser = (user: User) => {
  if (user.name === undefined) {
    throw new Error('Missing name');
  }
  
  const name = getName(user);
  
  // ...
}

const getName = (user: User): string  => {
  // Grrrr... Why do I have to do that again?
  if (user.name === undefined) {
    throw new Error('Missing name');
  }

  // ... and we just created a potential null exception
  return user.name!;
}
```

Consider this scenario, which is even more problematic: a function employs `undefined` to represent the action of "deleting a value." Here's what it might look like:

```ts
type User = { id: string, name?: string };

const updateUser = (user: User, newId: string, newName?: string) => {
  user.id = newId;
  user.name = newName;
}

updateUser(user, "123"); // It's unclear that this call actually removes the user's name.
```

In this example, using `undefined` ambiguously to indicate the deletion of a user's name could lead to confusion and maintenance issues. The code does not clearly convey that omitting `newName` results in removing the user's name, which can be misleading.

## A path forward

Instead of wrestling with null-ish values, consider whether they’re necessary. Utilizing unions or more descriptive data structures can streamline your approach, ensuring clarity and reducing the need for null checks.

```ts
type User = { id: string };

type NamedUser = User & { name: string };

const getName = (user: NamedUser): string => user.name;
```

You can also have a data structure to clearly indicate the absence of something, for example: 

```ts
type User = {
  id: string;
  name: { kind: "Anonymous" } | { kind: "Named", name: string }
}
```

If we jump back to my first example of updating a user, here is a refactored version of it:

```ts
type UpdateUser = {
  name:
    | { kind: "Ignore" }
    | { kind: "Delete" }
    | { kind: "Update"; newValue: string };
};

```

This model explicitly delineates intent, paving the way for cleaner, more intuitive code.

Some languages have completely abandoned the `null` value to embrace optional values instead. In Rust for example, there is neither `null` or `undefined`, instead you have the `Option` enum.

```ts
type Option<T> = Some<T> | None;

type Some<T> = { kind: "Some", value: T };

type None = { kind: "None" };
```

I recommend this lib if you want to try this pattern in JS: https://swan-io.github.io/boxed/getting-started


## Conclusion

Adopting refined practices for dealing with `null` and `undefined` can dramatically enhance code quality and reduce bugs. Let the evolution of languages and libraries inspire you to embrace patterns that prioritize clarity and safety. By methodically refactoring our codebases, we can make them more robust and maintainable. This doesn't imply you should entirely abandon `undefined` or `null`; rather, use them thoughtfully and deliberately, not merely because they're convenient and straightforward.