Functions that take collection parameters should take the generic parameter. E.g. don’t do this:
public void process(ArrayList list);
Import statements provide good documentation, but not if they contain wildcards. For example:
import com.zikzak.db.*;
import com.zikzak.util.*;
No function should ever throw a RuntimeException by design, unless it has documented requirements for its arguments or object state that are not fulfilled. Essentially, it must always be possible for the caller of a function to do enough checking so that it can be sure no RuntimeException will be thrown.
throws Exception or throws ThrowableUsing throws Throwable and throws Exception subverts the exception checking system. If you do this, callers are forced to catch Throwable or Exception, which may catch both unchecked and checked exceptions. This forces callers to use instanceof to see whether the exception is one that they can deal with.
Put TestCase classes in the same package as the class they are testing. This makes it easy to test protected and package-visible methods. It’s still a pain to test private methods though.
If a function that returns an object is unable to return the object because of an error, it should not return null. Instead, it should throw some defined exception. This means that the handling for the error can occur at the appropriate place, by catching the defined exception. This appropriate place may be at the […]
All code must compile without warnings. All warnings must be fixed before checking code in to a version control system. This applies not only to compiled languages: for example, validation of HTML or CSS code should also be warning-free for the same reasons given here.
In a multi-layered architecture, the data access layer should hide database foibles. For example, Oracle stores empty strings as null – this should be hidden in the data access layer by specifying function return values appropriately. For example, ensure that the layer never returns a null string: null strings returned from the database should be […]
Think carefully before using an automatically-generated unique ID as a primary key in a SQL table. Using such automatically-generated IDs introduces extra implementation detail. This is a pain to manage, especially if they are used as primary keys or worse, foreign keys in tables.