Checks visibility of class members. Only static final members may be public; other class members must be private unless the property protectedAllowed or packageAllowed is set.
Public members are not flagged if the name matches the public member regular expression (contains "^serialVersionUID$" by default).
Note that Checkstyle 2 used to include "^f[A-Z][a-zA-Z0-9]*$" in the default pattern to allow names used in container-managed persistence for Enterprise JavaBeans (EJB) 1.1 with the default settings. With EJB 2.0 it is no longer necessary to have public access for persistent fields, so the default has been changed.
Rationale: Enforce encapsulation.
name | description | type | default value |
---|---|---|---|
packageAllowed | whether package visible members are allowed | boolean | false |
protectedAllowed | whether protected members are allowed | boolean | false |
publicMemberPattern | pattern for public members that should be ignored | regular expression | ^serialVersionUID$ |
To configure the check:
<module name="VisibilityModifier"/>
To configure the check so that it allows package visible members:
<module name="VisibilityModifier"> <property name="packageAllowed" value="true"/> </module>
To configure the check so that it allows no public members:
<module name="VisibilityModifier"> <property name="publicMemberPattern" value="^$"/> </module>
Implements Joshua Bloch, Effective Java, Item 17 - Use Interfaces only to define types.
According to Bloch, an interface should describe a type. It is therefore inappropriate to define an interface that does not contain any methods but only constants. The Standard class javax.swing.SwingConstants is an example of a class that would be flagged by this check.
The check can be configured to also disallow marker interfaces like java.io.Serializable, that do not contain methods or constants at all.
name | description | type | default value |
---|---|---|---|
allowMarkerInterfaces | Controls whether marker interfaces like Serializable are allowed. | Boolean | true |
Makes sure that utility classes (classes that contain only static methods or fields in their API) do not have a public constructor.
Rationale: Instantiating utility classes does not make sense. Hence the constructors should either be private or (if you want to allow subclassing) protected. A common mistake is forgetting to hide the default constructor.
If you make the constructor protected you may want to consider the following constructor implementation technique to disallow instantiating subclasses:
public class StringUtils // not final to allow subclassing { protected StringUtils() { // prevents calls from subclass throw new UnsupportedOperationException(); } public static int count(char c, String s) { // ... } }
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, nonstatic methods of classes that can be subclassed must
Rationale: This API design style protects superclasses against being 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 superclass's method.
Ensures that exception classes (classes with names conforming to some regular expression) are immutable, that is, that they have only final fields.
The current algorithm is very simple: it checks that all members of exception are final. The user can still mutate an exception's instance (e.g. Throwable has a method called setStackTrace which changes the exception's 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 set the initial state. In both cases, code catching the exception could draw incorrect conclusions based on the state.
name | description | type | default value |
---|---|---|---|
format | pattern for exception class names | regular expression | ^.*Exception$|^.*Error$ |
Restricts throws statements to a specified count (1 by default).
Rationale: Exceptions form part of a method's interface. Declaring a method to throw too many differently rooted exceptions makes exception handling onerous and leads to poor programming practices such as writing code like catch(Exception ex). This check forces developers to put exceptions into a hierarchy such that in the simplest case, only one type of exception need be checked for by a caller but any subclasses can be caught specifically if necessary.
name | description | type | default value |
---|---|---|---|
max | maximum allowed number of throws statements | Integer | 1 |
To configure the check so that it doesn't allow more than two throws per method:
<module name="ThrowsCount"> <property name="max" value="2"/> </module>
Check nested (inner) classes/interfaces are declared at the bottom of the class after all method and field declarations.
Checks that each top-level class, interface or enum resides in a source file of its own. Official description of a 'top-level' term:7.6. Top Level Type Declarations. If file doesn't contains public class, enum or interface, top-level type is the first type in file.
An example of check's configuration:
<module name="OneTopLevelClass"/>
An example of check's configuration applied only to classes:
<module name="OneTopLevelClass"> <property name="tokens" value="CLASS_DEF"> </module>
An example of code with violations:
public class Foo{ //methods } class Foo2{ //methods }
An example of code without public top-level type:
class Foo{ // top-level class //methods } class Foo2{ //methods }
An example of code without violations:
public class Foo{ //methods }