nil is a subtle code smell that is present in many Swift codebases. What is it? Why is it a problem? How can we solve it?
Originally published at mczarnik.com.
Let’s take a brief, made up and very contrived example. Let’s say there is a method in your codebase that presents a view with an animation.
You’ve seen this invocation in your code many, many times.
What does it mean that
animation parameter is
Every time you’ve been going through this line of code you’ve been asking yourself this question. There are at least four ways you can figure this out:
- If you work in a team and API is a craft of your teammates you can ask them
- But why should you — there’s no secrets and after some time of digging you can easily get the answer
- You can run your code couple of times or unit test it (if possible) and figure it out
- You can assume that it is reasonably written and
nilas a parameter means “no animation at all”
Whatever way you decided to follow the answer is:
If you pass
nilto this method your view will be presented with the animation, that starts from the bottom of the screen.
Obvious, right? No, it’s not obvious. It’s not even logical. The example is very contrived, but I hope you get what the problem is.
What’s the problem?
Whatever choice you’ve made to get to this information why have you had to ask this question to yourself at all? Good API is self explanatory and every necessity to explain what it does or how it will perform given certain input is a failure of it’s designer. It’s like with physical things — the best designs doesn’t have to be explained, you just get it.
The problem here originates from the optional overuse. The meaning of optional is strict. It means:
there is a value, and it equals x or there isn’t a value at all
Nothing more. That’s it. In our case the definition of
nil is “default animation from the bottom of the screen”. This
nil has a meaning, but it’s meaning is different. This is what I call an anonymous
nil - it’s a
nil that is used as an actual parameter or variable/constant that means something more than “no value at all”.
What are the consequences?
Wherever you use a
nil as a value that has a particular meaning (and it’s not a “no value at all”) you’re making users of your API (including future self) sad:
- They can waste time digging to figure out what does this
nilmean (sometimes the answer may be hidden really deep down)
- They can encounter many other methods that use similar signature, but every time they see them they need to ask themselves if the rule from the other method still holds true in similar places?
- They need to maintain volatile meta-knowledge about the API in their head
- They can even have wrong assumptions about the system’s behaviour
How can you make it better?
Often we can’t afford to make a proper dependency injection or DI is not the right tool to solve this kind of issue. Let’s try to understand the problem a bit more and come up with feasible, lightweight solution.
In our case there are two possible outcomes for the method:
- Animation will pop up from the bottom
- Specific, non-
nilanimation will be executed
Isn’t it like an
enum with two cases? Yes, indeed. What if we use such enum in our code? That’s simple:
Now there is no ambiguity on the call side:
How about implementation side? To be able to use
Animation object inside we need to extend our enum to unwrap the wrapped value.
So somewhere deeper we can write:
You can easily adapt this solution to be generic or use parameters in the
The example here is contrived and oversimplified, but I hope I’ve highlighted an issue and sensitized you to this subtle problem.
I’m Maciek Czarnik
iOS Developer, musician, maker. Passionate about building beautiful, robust, useful and user-friendly apps.