Why I banned ‘null’ from my Javascript code and why you should too

There are only two kinds of languages: the ones people complain about and the ones nobody uses.
— Bjarne Stroustrup, creator of C++

I love Javascript and the freedom that comes with it, but some of its parts are definitely broken. I recently realized that the null keyword is one of those parts and decided to remove it altogether from the code I write. Here are the main reasons why.

DRY

Don’t repeat yourself. Javascript already has the undefined type to indicate the absence of value, so there is absolutely no need to have a second type that represent the same concept.

Having to worry about null means you would have to write code like this every time:

if (x === undefined || x === null) {
  // do your stuff...
}

Some of you might argue that we could define a predicate function to overcome the problem:

const isNil = x === undefined || x === null

I am not an advocate for micro-optimizations, but defining a function only for this purpose adds unnecessary overhead.

Also, one might argue that we could use the == operator when comparing with null:

However, the == operator has so many weird behaviors due to type coercion that its usage is usually frowned upon by the Javascript community. Also, the default behavior for the eqeqeq—used by many popular style guides — ESLint rule is to mark all == occurrences as an error (this behavior can be changed through configuration options though).

Safer typeof operator

I like to use the typeof operator for quick and dirty type checking. While it is not the most reliable way, it works well for some use cases, such as checking if a variable contains a function.

However, if you try to use it with null, the result might surprise you:

Javascript being Javascript! ¯\_(ツ)_/¯

Null breaks default parameters

Default parameters are probably in the top 3 ES6+ features I use the most when writing code targeting modern environments (node.js ≥ 6, not IE). However, they only work if the value of the parameter is undefined. See the code bellow:

Well, fuck!

This example is a bit convoluted, but imagine that the parameter of the high order function is a variable whose value comes from another part of the code. If it can be null, the code will break. You would have to write guard-checks to prevent this, but this is the exact same thing default parameters try to avoid.

Null breaks object destructuring defaults

Another ES6+ feature in my top 3 is object destructuring. It supports default values for keys that don’t exist or are set to undefined. Once again, using null means that the default value will not be used:

It gets worse when you try to use nested destructuring, since the script will throw an error when we try to destructure null:

Where should I still use null?

The only reason I can think of is integration with libraries/APIs which use null. For example, the knex.js library for building SQL queries does not get along with undefined values, so you must use null.

Beware that you should not let nulls leak into other layers. This will require you to write some boilerplate code to convert back and forth between null and undefined.

Okay, I’m convinced. How do I enforce this?

I recently found this ESLint plugin. All you need to do is add no-null to your .eslintrc:

{
  "plugins": [
    "no-null"
  ],
  "rules": {
    "no-null/no-null": 2
  }
}

If you don’t want it to be an error, change to 1 to get warnings:

{
  "plugins": [
    "no-null"
  ],
  "rules": {
    "no-null/no-null": 1
  }
}

That’s all folks!