Jul 16 2017 · Software Engineering
One of my favorite videos is Null Island from Minute Earth. I frequently link to it when I get into a discussion about whether null is an acceptable value for a certain use case.
What I really like is the definition around null and the focus of null having a concrete definition, that is: “we don’t know”. When used in this way, we have a clear understanding of what null is and the context in which it’s used (whether some field in a relational table, JSON object, value object, etc.) inherits this definition (i.e. “it’s either this value or we don’t know”), yielding something that’s fairly easy to reason about.
When nulls are ill-defined or have multiple definitions, complexity and confusion grow. Null is not:
- Empty set
- Empty string
- Invalid value
- A flag value for an error
Equating null to any of the above means that if you come across a null, you need to dig deeper into your code or database to figure out what that null actually means.
The flip side of this is avoiding nulls altogether, and there are really 2 cases here:
- There is no need for null (i.e. we do know what the value is, in every use case)
- Architect the system such that a null isn’t surfaced
In the first case, null doesn’t fit the use case, so there’s no need for it. When possible, this is ideal, and you avoid the necessity for null checks.
For the second case, architecting this way always seems to involve adding more complexity, to the point where it’s questionable if there’s a net benefit.