This past week I was looking over a number of merge requests and some of them had new methods declared with a return type of String (these are Java classes). With all of these methods if there is a logic issue or some unexpected behaviour then instead of returning an empty String object they all returned null. Personally this starts ringing alarm bells and waving red flags. Why is that you may ask?
If nulls are being returned, passed around to other methods, etc then the programmer will need to check before using that object (well they should anyway). There have been numerous times where I have seen programmers completely ignoring a null check for an object even though the method they used before to set that object could potentially return a null. With every one of these cases I politely leave a comment on the merge request, waiting until an update commit with the null checks are added before merging. Better safe than sorry.
Now am I being too cautious? I tend to lean towards the overly cautious side because it does not take much more lines of code and effort to ensure that the appropriate logging and checks are in place so that unexpected errors and problems with the software are not encountered by the user; plus it means that the software you are writing is safer. Let me know how you handle situations like this. Talking to some of the other programmers I know, they are split on the subject. Some don’t really care what is returned and don’t bother checking the object before use (those I call cowboy programmers), some don’t really care what is returned but do check before the object is used, and some care about what is returned and always check the object before use (I fall into this camp).
Potentially this problem is solved on a case by case basis. Is there a valid reason a null object should be returned? I’ll be doing some more reading about this to get a better understanding to ensure that I adhere to proper programming etiquette and safe programming.