Zero is a number
I won’t bore you with the story of how long it took for people to recognize that zero is a number. Without zero it would be difficult to explain what is the value of, say, 3 minus 3; we’d be forced to say that it’s a “meaningless” expression. Funny huh? Yet some developers seem to be stuck to medieval thinking in this respect.
Have you ever seen code like this?
public ListfindAllEmployeesByDepartment(int departmentId) { String sql = "select * from employees where department_id = ?"; ResultSet rs = select(sql, department_id); if (rs.size() == 0) { return null; } else { // ... convert the recordset to a List and return it } }
This developer seems to think that an empty List is not a regular list, so he thinks he should return a special value like null
to signal that the query returned no values. This is totally unnecessary. No, I take it back: this is totally wrong. You are forcing all callers of findAllEmployeesByDepartment
to check for null. Not only that; this code seem to say that it’s a totally unnatural and unexpected thing for this query to return no rows. Soon developers will forget to check for null, and the application will throw NullPointerException
s.
A related example is:
Foo[] foos = ...; if (foos.length > 0) { for (int i=0; i < foos.length; i++) { // do something with foo[i] } }
Here the developer thinks that they have to treat the case of an empty array separately. In fact the IF is totally unnecessary. If the array is empty, the loop would execute zero times anyway. Java (and C) arrays use asymmetric bounds, which make it easier to write code that does not need to treat a zero-size interval as a special case.
In conclusion: empty collections are perfectly valid collections, and empty arrays are perfectly valid arrays. It’s a good idea to write code that doesn’t treat “zero” as a special case.
This post is part of a series on development fundamentals.
August 6th, 2010 at 16:42
I completely agree!
And you can even push it a little bit forward: some times you need to create and return a NullObject instead of simple null. But since this would mean adding code and complexity (a new class), it is to be used only if and when it is really needed.
Some references to the NullObject design pattern:
http://www.cs.oberlin.edu/~jwalker/nullObjPattern/
http://www.refactoring.com/catalog/introduceNullObject.html
http://martinfowler.com/eaaCatalog/specialCase.html
August 27th, 2010 at 10:39
I totally agree with Vieri: IMHO this is a specific instance of the NullObject way of thinking about OO messages ;)
October 12th, 2010 at 14:53
Hi Matteo,
of course I fully agree with your observations but (here I’m going a little off-topic) I think it’s very difficult to avoid the 0 check on Java. Yes, theoretically a developer must never return null but this is a convention, there are no built-in rules in the language (you can make use of jsr-305 but that is not 100% bulletproof). How one can be sure that a method returns always an empty list? If you hold the control on code it’s perfectly ok, otherwise you can read the source code but what if the implementation changes? I have learned a lot of things reading java.util.Collections class which I think in this respect is a jewel.