The Design Ruleset contains a collection of rules that find questionable designs. If you have a class that has nothing but static methods, consider making it a Singleton 3 Avoid using implementation types (i.e., HashSet); use the interface (i.e, Set) instead 3 Avoid unnecessary if..then..else statements when returning a boolean 3 Switch statements should have a default label. 3 Deeply nested if..then statements are hard to read. 3 y) { if (y>z) { if (z==x) { // this is officially out of control now } } } } } ]]> Reassigning values to parameters is a questionable practice. Use a temporary local variable instead. 2 A high ratio of statements to labels in a switch statement implies that the switch statement is doing too much work. Consider moving the statements either into new methods, or creating subclasses based on the switch variable. 3 Calling overridable methods during construction poses a risk of invoking methods on an incompletely constructed object. This situation can be difficult to discern. It may leave the sub-class unable to construct its superclass or forced to replicate the construction process completely within itself, losing the ability to call super(). If the default constructor contains a call to an overridable method, the subclass may be completely uninstantiable. 1 Instantiation by way of private constructors from outside of the constructor's class often causes the generation of an accessor. A factory method, or non-privitization of the constructor can eliminate this situation. The generated class file is actually an interface. It gives the accessing class the ability to invoke a new hidden package scope constructor that takes the interface as a supplementary parameter. This turns a private constructor effectively into one with package scope, though not visible to the naked eye. 3