Scalastyle proposed rules (Class Design)

This page contains proposed rules for Scalastyle, for the category Class Design.

Class Design

VisibilityModifier

Checks visibility of class members. Members must be private unless property protectedAllowed or packageAllowed is set. Rationale: Enforce encapsulation.

TraitIsType

Implements Bloch, Effective Java, Item 17 - Use Traits only to define types. According to Bloch, an interface should describe a type. It is therefore inappropriate to define a trait that does not contain any methods but only constants. The check can be configured to also disallow marker interfaces like java.io.Serializable, that do not contain methods or constants at all.

DesignForExtension

Checks that classes are designed for extension. More specifically, it enforces a programming style where superclasses provide empty "hooks" that can be implemented by subclasses. The exact rule is that nonprivate methods of classes that can be subclassed must either be

• abstract or
• final or
• have an empty implementation

Rationale: This API design style protects superclasses against beeing broken by subclasses. The downside is that subclasses are limited in their flexibility, in particular they cannot prevent execution of code in the superclass, but that also means that subclasses cannot corrupt the state of the superclass by forgetting to call the super method.

MutableException

Ensures that exceptions (defined as any class name conforming to some regular expression) are immutable. That is, have only final fields. The current algorithm is very simple it checks that all members of exception are final. User can still mutates an exception's instance (e.g. Throwable has setStackTrace(StackTraceElement[] stackTrace) method which changes stack trace). But, at least, all information provided by this exception type is unchangable. Rationale: Exception instances should represent an error condition. Having non final fields not only allows the state to be modified by accident and therefore mask the original condition but also allows developers to accidentally forget to initialise state thereby leading to code catching the exception to draw incorrect conclusions based on the state.

ThrowsCount

Restricts throws statements to a specified count (default = 1). Rationale: Exceptions form part of a methods interface. Declaring a method to throw too many differently rooted exceptions makes exception handling onerous and leads to poor programming practices such as catch (Exception). This check forces developers to put exceptions into a heirachy such that in the simplest case, only one type of exception need be checked for by a caller but allows any sub-classes to be caught specifically if necessary.

InnerTypeLast

Check nested (internal) classes/interfaces are declared at the bottom of the class after all method and field declarations.