The null pattern haunted house

Have you faced a bug, in a pretty standard code and when you find the problem, you cannot say if its a business logic or just some type check to avoid null pointer exception? Those kind of bugs for me are the worst, they took me more time just to figure out why its there that then actually fixing the problem. That's something that happen to me more often that I would like to, so let's talk about this and complain together.

Disclaimer: This discussion is bigger than this article, there are even people who like this null pattern! 🤷‍️. Sometimes I think the problem is that you actually don't mind a null check and don't take it as a problem, you know, its just a null check! What wrong can come from this? And here is when this pattern can be a bogeyman.

For me, if your software throws a null pointer, its something good! You'r work is to prevent this to happen, and not to check every bite of data for a null. Its not a witch hunt! they are there to explode and give's you some feedback of a potential bug, remember: Fail fast! We'll dig about this in another article.

I have a case that can spot this problem: I was working on an application for news, and there was an business logic that if the front-end send an published date, this news should be released to the users, otherwise this news is a draft, even more, the software should convert this date from string to timestamp.

So far so good, seems a quite simple task, and the backend code was something like this:

So we have a method who convert a string to a timestamp, and it's actually doing business logic! Not only this null check is not at its proper place to create a unit with its method, but he is hiding the implementation on a helper method.

Giving nothing to receive nothing…

Let's imagine that you are working at a cake line at a bakery. Your job is receive a cake shape, add flour and give it back; If the previous employee don'g gives the shape, would you add flour on nothing and give back nothing?No! You probably would complain! It's a side-effect though.

By returning nothing you are not assuming the responsibility for your code and passing the problem for the rest of the system, a problem that is hard to get to, I'll tell you a hole weekend of pain that I had with a simple null Scheißa

It was a sunny weekend at a hot Brazilian summer, air conditioners working at its maximum and there I was, trying to deploy a project with the client doing the QA. Everything fine until they find a mysterious bug. Some date have been saved as null in a new software process. I was the only developer at the company, a project with more than 40 developers, and no previous knowledge of this particular part of the system. 2 hours of debug later and I end up with a small piece of code: if(date == null) return null; checking the gitlog, this was a "bugfix" for some problem from the front-end. It took me more than an hour to understand why a null is solving an issue of our ferocious angular application. Hours of a sweeting coding day and 3 lines changed, one null code removed and the bug was solved.

So what should I do? How to live without null and its "helpful" abilities? Well, let it blow! Chaos give us direction, show us problems and where to act! If you code never fail, how can you know that it is working?

The null pattern haunted house was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.