FindBugs advice

I’ve been looking at the FindBugs tool written by undergraduate students at the University of Maryland. As the name suggests, FindBugs scans your source code and look for things that at best, a compiler may flag as a warning or just complete ignore. What has impressed me about the tool is not that it caught so many problems in the code, it is the quality of the advice that it gives regarding what it found and suggestions on how one might fix the problem. For example, I had a couple of methods that returned null. FindBugs classified that practice as "Dodgy" and then offered up this advice.

Consider returning a zero length array rather than null It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method. On the other hand, using null to indicate "there is no answer to this question", then it is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

Being someone who is focused on performance, my first thought was, now that is a good way to create a lot of extra garbage. But immediately following that thought came a memory from my days as a Smalltalk programmer. Smalltalk place holders (variables) are not typed. Now one may think that would lead to a whole host of problems but in practice, it didn’t. One of the reasons is that place holder names implied intent. Using names that implied intent suggested to developers which types of object should be assigned to the place holder. The contra positive of this is that developers tended not to assign unintended objects to the place holder. The fallout from this is that properly written Smalltalk methods should never return nil (or null in Java). The result was that code could be normalized or IOWs, written in such a way that you never had to worry about null pointer exceptions (in Smalltalk, since nil is an object, this would be a method not found exception). The take-away from this is that not returning null is actually consistent with the message that I give in my performance tuning course, good design and coding practices should win. In this case the lesson learned from Smalltalk still applies in Java. However it is a lesson that I had somehow forgotten. Thank you FindBugs!

tags: java  performance  good  design  findbug