4 min read

Opinion on nullable collections

Opinion on nullable collections
Photo by Galen Crout / Unsplash

Recently I touched upon one of my pet peeves regarding development—nullable data. I thought to start being like a LinkedIn influencer. Spend some time to create some pretty graphics about my own opinion. In contrast to a number of the aforementioned, that just take a book and illustrate it. Then again, I believe that being able to express your opinion in a verbal or written way helps you learn how to work in a team. And how to work with people who don't agree with your views and opinions. So gonna learn how to be an influencer later on.

To start off this new series of posts I wish to do, I would like to continue expanding on the original post and go from there. Who knows, I just know that like the next developer in line, I do have a lot of opinions.

The collection in code, in whatever form and shape is a grouping of correlated entities. I will try staying agnostic of languages here, as I am aware you can do a lot of things depending on your language of choice. Then again, just because you can doesn't mean you should. I have never come across a scenario where I would need to do something like this and there was not some need to be "grouped" together.

When I think of collections in code, my brain goes to a bucket. And I mean real-world bucket. Or some sort of a container, that can contain "stuff" in it. Now, everything that goes inside of this bucket/container I consider to be related, whoever weird those examples could be. They are going to be in the same place, together. This is just a boundary that indicates that these things come together. Now, let us think about what happens when there is no bucket or container. Those things you meant to group together, still exist. While that container is just not there. So I need to go and make/borrow one, so I can place things inside of it.

Photo by Francesco Ungaro / Unsplash

That is what is in my head when I come across NULL-able collection. You first need to make a bucket, before you can put anything inside of it? Which seems odd to me, in any form or fashion.Especially when I think of taking out something from this bucket. Why should I need to check for the existence of it, before I can get something out of it?

if bucket is null
 item = null
 item = bucket.first

I don't know about you, but this makes me scratch my head every time. And it is an understatement to say I see this kind of code often. Comments I get more often when asked why: Looks cleaner if I omit this. I am not sure at what point in time clean code started to mean these kinds of things. And yet it is normal to have you check for the existence of something you originally created in the first place.

// When having a need to create a collection in my code, 
// it will be initialized as empty. 
type Example {
 ctor {
  bucket = bucket.empty

For the sake of a number of frameworks out there that we use on a daily basis, I will also "allow" it to be overridden by a new reference. I consider this a code smell, but you need to pick your battles. Simply because that is like saying: I have a bucket here and instead of moving stuff from the other one into the current one, I will just take the second one. And disregard the first one entirely. This is where I would say: For the sake of that framework and quality of life features, leave it, the first bucket in this example, as NULL-able.

type ExampleDTO {
 bucket = null

There is no "depends" here. It is a simple choice that you need to make, what do you feel comfortable with? I am not someone who will make a big deal out of it, I could ask a question and we can have a discussion about it. I have my own opinions on what I consider " good" code. That is subjective and personal preference when it comes to things like these. It is not empirically proving your code is better this way.

This is an opinionated piece, so please keep that in mind when engaging in debates with individuals who may hold different viewpoints. It's intended to foster interesting discussions where people can exchange knowledge rather than serve as a hindrance to progress. Both approaches are valid, so choose your preferred method, but ensure you can articulate your rationale for doing so. In the context of a pull request, I view this as a recommendation rather than a strict requirement. What I'm emphasizing is the importance of recognizing that not everyone will share your opinions on code. Just as people may not agree on scientifically established facts today, imagine the diversity of approaches in a field where numerous methods are feasible. It's essential to stand by your opinions, engage in constructive arguments, and, when necessary, find common ground to advance.

Until next time, the bucket is an illusion.