Checks for Coding problems
Checks for Coding problems |
+ |
+
+
|
+
+
+ EqualsHashCode+Description++ Checks that classes that override equals() also + override hashCode(). + ++ Rationale: The contract of equals() and + hashCode() requires that equal objects have the same hashCode. Hence, + whenever you override equals() you must override + hashCode() to ensure that your class can be used in collections that are + hash based. + + +Example++ To configure the check: + ++<module name="EqualsHashCode"/> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + +HiddenFieldDescription++ Checks that a local variable or a parameter does not shadow a field that is + defined in the same class. + +Properties+
Examples++ To configure the check: + ++<module name="HiddenField"/> ++ + To configure the check so that it checks local variables but not parameters: + ++<module name="HiddenField"> + <property name="tokens" value="VARIABLE_DEF"/> +</module> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + +IllegalInstantiationDescription++ Checks for illegal instantiations where a factory method is preferred. + ++ Rationale: Depending on the project, for some classes it might be preferable to + create instances through factory methods rather than calling the constructor. + ++ A simple example is the java.lang.Boolean class. In + order to save memory and CPU cycles, it is preferable to use the predefined + constants + TRUE and FALSE. Constructor invocations should + be replaced by calls to Boolean.valueOf(). + ++ Some extremely performance sensitive projects may require the use of factory + methods for other classes as well, to enforce the usage of number caches or + object pools. + +Notes++ There is a limitation that it is currently not possible to specify array classes. + +
Example++ To configure the check to find instantiations of java.lang.Boolean: + ++<module name="IllegalInstantiation"> + <property name="classes" value="java.lang.Boolean"/> +</module> ++ + Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + +InnerAssignmentDescription++ Checks for assignments in subexpressions, such as in String s + = Integer.toString(i = 2);. + ++ Rationale: With the exception of for iterators, all + assignments should occur in their own toplevel statement to increase readability. + With inner assignments like the above it is difficult to see all places where a + variable is set. + +Properties+
Examples++ To configure the check: + ++<module name="InnerAssignment"/> ++ + To configure the check for only =, + +=, and -= operators: + ++<module name="InnerAssignment"> + <property name="tokens" value="ASSIGN,PLUS_ASSIGN,MINUS_ASSIGN"/> +</module> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + +MissingSwitchDefaultDescription++ Checks that switch statement has "default" clause. + ++ Rationale: It's usually a good idea to introduce a default case + in every switch statement. Even if the developer is sure that + all currently possible cases are covered, this should be + expressed in the default branch, e.g. by using an + assertion. This way the code is protected aginst later changes, + e.g. introduction of new types in an enumeration type. + +Examples++ To configure the check: + ++<module name="MissingSwitchDefault"/> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + +SimplifyBooleanExpression+Description++ Checks for overly complicated boolean expressions. Currently finds code like + if (b == true), b || true, !false, etc. + ++ Rationale: Complex boolean logic makes code hard to understand and maintain. + +Example++ To configure the check: + ++<module name="SimplifyBooleanExpression"/> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + +SimplifyBooleanReturnDescription++ Checks for overly complicated boolean return statements. For example the following code + ++if (valid()) + return false; +else + return true; ++ + could be written as + ++return !valid(); ++ + The Idea for this Check has been shamelessly stolen + from the equivalent PMD rule. + +Example++ To configure the check: + ++<module name="SimplifyBooleanReturn"/> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + +AvoidInlineConditionalsDescription++ Detects inline conditionals. + + An example inline conditional is this: + +
+String a = getParameter("a");
+String b = (a==null || a.length<1) ? null : a.substring(1);
+
+ + Rationale: Some developers find inline conditionals hard to read, + so their company's coding standards forbids them. + +Examples++ To configure the check: + ++<module name="AvoidInlineConditionals"/> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + +DoubleCheckedLockingDescription++ The "double-checked locking" idiom (DCL) tries to avoid the runtime cost + of synchronization. An example that uses the DCL idiom is this: + +
+public class MySingleton
+{
+ private static theInstance = null;
+
+ private MySingleton() {}
+
+ public MySingleton getInstance() {
+ if ( theInstance == null ) { // synchronize only if necessary
+ synchronized( MySingleton.class ) {
+ if ( theInstance == null ) {
+ theInstance = new MySingleton();
+ }
+ }
+ }
+ }
+}
+
+ + The problem with the DCL idiom in Java is that it just does not work correctly. + Using it introduces bugs that are extremely hard to track down and reproduce. + The + "Double-Checked Locking is Broken" Declaration has an in depth explanation + of the exact problem which has to do with the semantics of the Java memory model. + ++ The DoubleCheckedLocking check will find source code where a test is wrapped in a + synchronized block that is wrapped in the same test, like in the example above. + +Examples++ To configure the check: + ++<module name="DoubleCheckedLocking"/> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + + |
+
+Copyright © 2002-2003 Oliver Burn. All rights Reserved. +
+ + + diff --git a/docs/config_design.html b/docs/config_design.html new file mode 100644 index 000000000..56b6c6073 --- /dev/null +++ b/docs/config_design.html @@ -0,0 +1,297 @@ + + + + +Class Design Checks |
+ |
+
+
|
+
+
+ VisibilityModifier++ Checks visibility of class members. Only static final members + may be public; other class members must be private unless + 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: + Checkstyle 2 used to include "^f[A-Z][a-zA-Z0-9]*$" in the default + pattern to allow CMP for EJB 1.1 with the default settings. + With EJB 2.0 it is not longer necessary to have public access + for persistent fields, hence the default has been changed. + ++ Rationale: Enforce encapsulation. + + + +Properties+
Examples++ 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> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + +FinalClass+ ++ Checks that a class which has only private constructors is declared as final. + +Example++ To configure the check: + ++<module name="FinalClass"/> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + +InterfaceIsTypeDescription++ Implements 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
+ Properties+
Examples++ To configure the check: + ++<module name="InterfaceIsType"/> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + +HideUtilityClassConstructorDescription++ Make sure that utility classes (classes that contain only static methods) + 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() {
+ throw new UnsupportedOperationException(); // prevents calls from subclass
+ }
+
+ public int count(char c, String s) {
+ // ...
+ }
+}
+
+ Examples++ To configure the check: + ++<module name="HideUtilityClassConstructor"/> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + +DesignForInheritanceDescription++ Checks that classes are designed for inheritance. + 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 either be + +
+ 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. + + +Properties+ None. + +Examples++ To configure the check: + ++<module name="DesignForInheritance"/> ++ Package++ com.puppycrawl.tools.checkstyle.checks + +Parent Module++ TreeWalker + + + + |
+
+Copyright © 2002-2003 Oliver Burn. All rights Reserved. +
+ + + diff --git a/docs/config_misc.html b/docs/config_misc.html index 012ad5081..71e02442b 100644 --- a/docs/config_misc.html +++ b/docs/config_misc.html @@ -22,33 +22,12 @@- Checks that classes that override equals() also - override hashCode(). -
-- Rationale: The contract of equals() and - hashCode() requires that equal objects have the same hashCode. Hence, - whenever you override equals() you must override - hashCode() to ensure that your class can be used in collections that are - hash based. -
+- To configure the check: -
--<module name="EqualsHashCode"/> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
A generic check for code problems - the user can search for any pattern. This is @@ -144,182 +81,6 @@ <module name="GenericIllegalRegexp"> <property name="format" value="System\.out\.println"/> </module> - -
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
-- Checks that a local variable or a parameter does not shadow a field that is - defined in the same class. -
-| name | -description | -type | -default value | -
|---|---|---|---|
| tokens | -tokens to check | -subset of tokens PARAMETER_DEF, VARIABLE_DEF | -PARAMETER_DEF, VARIABLE_DEF | -
- To configure the check: -
--<module name="HiddenField"/> --
- To configure the check so that it checks local variables but not parameters: -
--<module name="HiddenField"> - <property name="tokens" value="VARIABLE_DEF"/> -</module> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
-- Checks for illegal instantiations where a factory method is preferred. -
-- Rationale: Depending on the project, for some classes it might be preferable to - create instances through factory methods rather than calling the constructor. -
-- A simple example is the java.lang.Boolean class. In - order to save memory and CPU cycles, it is preferable to use the predefined - constants - TRUE and FALSE. Constructor invocations should - be replaced by calls to Boolean.valueOf(). -
-- Some extremely performance sensitive projects may require the use of factory - methods for other classes as well, to enforce the usage of number caches or - object pools. -
-- There is a limitation that it is currently not possible to specify array classes. -
-| name | -description | -type | -default value | -
|---|---|---|---|
| classes | -classes that should not be instantiated | -String Set | -{} | -
- To configure the check: -
--<module name="IllegalInstantiation"/> -- -
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
-- Checks for assignments in subexpressions, such as in String s - = Integer.toString(i = 2);. -
-- Rationale: With the exception of for iterators, all - assignments should occur in their own toplevel statement to increase readability. - With inner assignments like the above it is difficult to see all places where a - variable is set. -
-| name | -description | -type | -default value | -
|---|---|---|---|
| tokens | -assignments to check | -subset of tokens ASSIGN, BAND_ASSIGN, BOR_ASSIGN, BSR_ASSIGN, BXOR_ASSIGN, - DIV_ASSIGN, MINUS_ASSIGN, MOD_ASSIGN, PLUS_ASSIGN, SL_ASSIGN, SR_ASSIGN, - STAR_ASSIGN | -all tokens | -
- To configure the check: -
--<module name="InnerAssignment"/> --
- To configure the check for only =, - +=, and -= operators: -
--<module name="InnerAssignment"> - <property name="tokens" value="ASSIGN,PLUS_ASSIGN,MINUS_ASSIGN"/> -</module> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
-- Checks that switch statement has "default" clause. -
-- Rationale: It's usually a good idea to introduce a default case - in every switch statement. Even if the developer is sure that - all currently possible cases are covered, this should be - expressed in the default branch, e.g. by using an - assertion. This way the code is protected aginst later changes, - e.g. introduction of new types in an enumeration type. -
-- To configure the check: -
-
-<module name="MissingSwitchDefault"/>
@@ -376,65 +137,6 @@
-- Checks for overly complicated boolean expressions. Currently finds code like - if (b == true), b || true, !false, etc. -
-- Rationale: Complex boolean logic makes code hard to understand and maintain. -
-- To configure the check: -
--<module name="SimplifyBooleanExpression"/> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
-- Checks for overly complicated boolean return statements. For example the following code -
--if (valid()) - return false; -else - return true; --
- could be written as -
--return !valid(); --
- The Idea for this Check has been shamelessly stolen - from the equivalent PMD rule. -
-- To configure the check: -
--<module name="SimplifyBooleanReturn"/> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
A check for TODO: comments. Actually it is a generic regular @@ -579,198 +281,6 @@ like 1.
-- Detects inline conditionals. - - An example inline conditional is this: -
-
-String a = getParameter("a");
-String b = (a==null || a.length<1) ? null : a.substring(1);
-
- - Rationale: Some developers find inline conditionals hard to read, - so their company's coding standards forbids them. -
-- To configure the check: -
--<module name="AvoidInlineConditionals"/> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
- -- Implements 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 | -
- To configure the check: -
--<module name="InterfaceIsType"/> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
- -- Make sure that utility classes (classes that contain only static methods) - 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() {
- throw new UnsupportedOperationException(); // prevents calls from subclass
- }
-
- public int count(char c, String s) {
- // ...
- }
-}
-
- - To configure the check: -
--<module name="HideUtilityClassConstructor"/> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
- -- Checks that classes are designed for inheritance. - 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 either be -
-- 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. -
- -| name | -description | -type | -default value | -
|---|---|---|---|
| javaStyle | -Controls whether to enforce Java style (true) or C style (false). | -Boolean | -true | -
- To configure the check to enforce Java style: -
--<module name="ArrayTypeStyle"/> --
- To configure the check to enforce C style: -
--<module name="ArrayTypeStyle"> - <property name="javaStyle" value="false"/> -</module> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
-Checks the style of array type definitions. @@ -871,51 +381,6 @@ public class StringUtils // not final to allow subclassing TreeWalker
-- The "double-checked locking" idiom (DCL) tries to avoid the runtime cost - of synchronization. An example that uses the DCL idiom is this: -
-
-public class MySingleton
-{
- private theInstance = null;
-
- private MySingleton() {}
-
- public MySingleton getInstance() {
- if ( theInstance == null ) { // synchronize only if necessary
- synchronized( MySingleton.class ) {
- if ( s_singleton == null ) {
- theInstance = new MySingleton();
- }
- }
- }
- }
-}
-
- - The problem with the DCL idiom in Java is that it just does not work correctly. - Using it introduces bugs that are extremely hard to track down and reproduce. - The - "Double-Checked Locking is Broken" Declaration has an in depth explanation - of the exact problem which has to do with the semantics of the Java memory model. -
-- To configure the check: -
--<module name="DoubleCheckedLocking"/> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
- Checks that a class which has only private constructors is declared as final. -
-- To configure the check: -
--<module name="FinalClass"/> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -
-@@ -178,87 +154,6 @@ Language specification, section 9.3).
-- Checks visibility of class members. Only static final members - may be public; other class members must be private unless - 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: - Checkstyle 2 used to include "^f[A-Z][a-zA-Z0-9]*$" in the default - pattern to allow CMP for EJB 1.1 with the default settings. - With EJB 2.0 it is not longer necessary to have public access - for persistent fields, hence 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> --
- com.puppycrawl.tools.checkstyle.checks -
-- TreeWalker -