Metrics
Restrict the number of number of &&, ||, &, | and ^ in an expression.
Rationale: Too many conditions leads to code that is difficult to read and hence debug and maintain.
Note that the operators & and | are not only integer bitwise operators, they are also the non-shortcut versions of the boolean operators && and ||.
| name | description | type | default value |
|---|---|---|---|
| max | the maximum allowed number of boolean operations in one expression. | integer | 3 |
| tokens | tokens to check | subset of tokens LAND, BAND, LOR, BOR, BXOR | LAND, BAND, LOR, BOR, BXOR |
To configure the check:
 |
|
|
|
<module name="BooleanExpressionComplexity"/> |
|
|
|
|
To configure the check with 7 allowed operation in boolean expression:
|
|
|
|
<module name="BooleanExpressionComplexity">
<property name="max" value="7"/>
</module> |
|
|
|
|
To configure the check to ignore & and |:
|
|
|
|
<module name="BooleanExpressionComplexity">
<property name="tokens" value="BXOR,LAND,LOR"/>
</module> |
|
|
|
|
com.puppycrawl.tools.checkstyle.checks.metrics
This metric measures the number of instantiations of other classes within the given class. This type of coupling is not caused by inheritance or the object oriented paradigm. Generally speaking, any abstract data type with other abstract data types as members has data abstraction coupling; therefore, if a class has a local variable that is an instantiation (object) of another class, there is data abstraction coupling. The higher the DAC, the more complex the data structure (classes) of the system.
| name | description | type | default value |
|---|---|---|---|
| max | the maximum threshold allowed | integer | 7 |
To configure the check:
|
|
|
|
<module name="ClassDataAbstractionCoupling"/> |
|
|
|
|
To configure the check with a threshold of 5:
|
|
|
|
<module name="ClassDataAbstractionCoupling">
<property name="max" value="5"/>
</module> |
|
|
|
|
com.puppycrawl.tools.checkstyle.checks.metrics
The number of other classes a given class relies on. Also the square of this has been shown to indicate the amount of maintenence required in functional programs (on a file basis) at least.
| name | description | type | default value |
|---|---|---|---|
| max | the maximum threshold allowed | integer | 20 |
To configure the check:
|
|
|
|
<module name="ClassFanOutComplexity"/> |
|
|
|
|
To configure the check with a threshold of 10:
|
|
|
|
<module name="ClassFanOutComplexity">
<property name="max" value="10"/>
</module> |
|
|
|
|
com.puppycrawl.tools.checkstyle.checks.metrics
Checks cyclomatic complexity against a specified limit. The complexity is measured by the number of if, while, do, for, ?:, catch, switch, case statements, and operators && and || (plus one) in the body of a constructor, method, static initializer, or instance initializer. It is a measure of the minimum number of possible paths through the source and therefore the number of required tests. Generally 1-4 is considered good, 5-7 ok, 8-10 consider re-factoring, and 11+ re-factor now!
| name | description | type | default value |
|---|---|---|---|
| max | the maximum threshold allowed | integer | 10 |
To configure the check:
|
|
|
|
<module name="CyclomaticComplexity"/> |
|
|
|
|
To configure the check with a threshold of 7:
|
|
|
|
<module name="CyclomaticComplexity">
<property name="max" value="7"/>
</module> |
|
|
|
|
com.puppycrawl.tools.checkstyle.checks.metrics
The NPATH metric computes the number of possible execution paths through a function. It takes into account the nesting of conditional statements and multi-part boolean expressions (e.g., A && B, C || D, etc.).
Rationale: Nejmeh says that his group had an informal NPATH limit of 200 on individual routines; functions that exceeded this value were candidates for further decomposition - or at least a closer look.
| name | description | type | default value |
|---|---|---|---|
| max | the maximum threshold allowed | integer | 200 |
To configure the check:
|
|
|
|
<module name="NPathComplexity"/> |
|
|
|
|
To configure the check with a threshold of 20:
|
|
|
|
<module name="NPathComplexity">
<property name="max" value="20"/>
</module> |
|
|
|
|
com.puppycrawl.tools.checkstyle.checks.metrics
Determines complexity of methods, classes and files by
counting the Non Commenting Source Statements (NCSS). This
check adheres to the
specification for the
JavaNCSS-Tool
written by Chr. Clemens Lee.
Rougly said the NCSS metric is calculated by
counting the source lines which are not comments, (nearly)
equivalent to counting the semicolons and opening curly
braces.
The NCSS for a class is summarized from the NCSS
of all its methods, the NCSS of its nested classes and the
number of member variable declarations.
The NCSS for a
file is summarized from the ncss of all its top level classes,
the number of imports and the package declaration.
Rationale: Too large methods and classes are hard to read and costly to maintain. A large NCSS number often means that a method or class has too many responsabilities and/or functionalities which should be decomposed into smaller units.
| name | description | type | default value |
|---|---|---|---|
| methodMaximum | the maximum allowed number of non commenting lines in a method. | integer | 50 |
| classMaximum | the maximum allowed number of non commenting lines in a class. | integer | 1500 |
| fileMaximum | the maximum allowed number of non commenting lines in a file including all top level and nested classes. | integer | 2000 |
To configure the check:
|
|
|
|
<module name="JavaNCSS"/> |
|
|
|
|
To configure the check with 40 allowed non commenting lines for a method:
|
|
|
|
<module name="JavaNCSS">
<property name="methodMaximum" value="40"/>
</module> |
|
|
|
|
com.puppycrawl.tools.checkstyle.checks.metrics