As you’re typing away at your keyboard, creating new objects and methods, you realize something.

“Hey, what if this object is actually null?”

And so, you decide to cleverly check if the object is null, like so :

public void doStuff(Object object){
  if(object != null){
    //Work your magic on this object
  }
}

However, there are several problems with this approach. For instance, most programmers who use this technique do nothing if the object is null. This causes huge amounts of bugs and headaches for everyone.

In addition, null checking an object everywhere causes excessive bloating. In fact, most of these checks are unnecessary. You should not be checking if an object is null inside the main parts of your code. It is best to only check when data is first passed in.

An analogy for this is as follows :

A city, known for its wealth and prosperity, lies in the middle of a desert. Every one in the city is confirmed to be a good citizen, and crime rates are at an all-time low 0%. However, one day, a group of vandals approach the city. As they reach the outskirts, they are caught and kicked out. No criminals allowed!

The city continues to prosper for the rest of eternity.

However, a few dozen miles away, another city named Nullville exists. Unlike the other city, Nullville has no guards around the city. As a result, the city is flooded with nasty and evil people. To combat these evil-doers, Nullville decides to enforce a strict system of identification, with all good people getting an ID.

If you want to go outside, you need to show your ID. If you want to buy meat, you need to show your ID. If you want to go home, you need to show your ID. If you want to sleep, you need to show your ID. If you are caught without an ID, you are booted from Nullville, as you’re proven to be evil.

Clearly, Nullville is in a terrible situation. In order to do anything in Nullville, you first have to actually prove that you have an ID (proving that you’re != null). Even if you aren’t serial killer or a thief, you still have to prove that you have an ID.

As a result, like Nullville, programmers end up excessively checking their data for nulls, when it simply isn’t necessary. As in the first city, data should be checked on the outskirts of your code, not inside the main parts of it.

If you force functions on the “outskirts” of your code base to check for nulls, then you do not have to check for nulls in the core sections. The output is already guaranteed to not be null, so there is no reason, in the input of another function, to check for null.

In a nutshell, a contract needs to be made. Function A promises to return an object, but it isn’t null. Function B accepts an object, but trusts function A that the object will not be null. As a result, there is no reason for function B to check its input for null.

So don’t bloat your code. Check for nulls at the gates of your code, so that you don’t have to do it inside the code.