Why Collections Should Never Be Null

After a long time of programming, I’ve realized that nulls are just evil, but what is worse is the idea that a collection can be null. This might be a provocative thing to say, or you might be on my side. I’ll try to explain myself and see if you agree with me.

Introduction

Every programming language has concepts centered around Set theory. If you are a C# programmer then you might know these sets by other names: Array, List, Collection, and Queue. There are many more than that. If you are unsure what a set is, then please allow me to explain?

A set is a well defined collection of objects. The objects that make up a set (also known as the elements or members of a set) can be anything: numbers, people, letters of the alphabet, other sets, and so on. – Wikipedia

So a set is just a group of stuff, seems simple enough right?

The Problem

In languages that support null values, a variable defined as a set can also itself be null. This can lead to situations where you get in trouble for asking questions about a specific set that is null. The number one question being the length of the set. This also leads to a lot of null checking that seems, to me at least, unnecessary.

My Argument

In .NET everything derives from the object class. This includes our favorite collections: List, Array, etc. This means that technically collections can be null, since they derive from object. This is an oversight by the .Net creators, since collections should fundamentally be a description of a set of 0 or more things. This means a set of nothing is a valid set, while nothing (null) is not a set by definition since it is not a group.

We deal with sets all the time in code, and an empty set is very useful. You might see things like this in your code or other codebases:

// Hey Set, How are you?
if (users.Any()) 
    DoSomething();

var max = Values.Max();
var min = Values.Min();

var hits = Punches.Sum();

Notice those descriptive methods still give you valuable information about the set, even if you imagine those sets are empty. I always do null checking on my sets, but why doesn’t the language just not allow sets to be null anymore and save us all a lot of time?

Workaround

This workaround isn’t a silver bullet, but I found it helps me a lot. I have also noticed, by skimming other projects on GitHub, that this is a more common problem than you think.

public class User {

    public User() {
       // a new user gets a new set
       Phones = new List<string>();
    }

    public IList<string> Phones { get; set; }
} 

You just set the collection / set in the constructor and it should be safe to start off with. The only issue is that the set operator is still exposed. You could solve this by not exposing it; this can be accomplished by using the protected or private keywords.

Conclusion

Some might argue that nulls are valuable, and I do recognize their value in some circumstances, but when it comes to collections it does not make any sense to allow them to be null. This would be near the top of the wish list in any new language / framework. Microsoft, if you are reading this, then I beg you to consider making this fix in the next version of the .Net Framework, or at least tell me why I’m wrong.