Why null is an abomination

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."

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:

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, 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:

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:

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:

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.

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.

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?

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:

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.

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:

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:

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.

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.