Java Developer Tools

CodePro Audit Rule Set

/h1>

The Elements of Java Style

Powered by CodePro and Eclipse


Summary

Block Depth
Brace Position
Class Naming Convention
Constant Field Naming Convention
Constructors Only Invoke Final Methods
Cyclomatic Complexity
Dangling Else
Empty Catch Clause
Empty Finally Clause
Empty Statement
Empty Synchronized Statement
Explicit "this" Usage
Field Javadoc Conventions
File Comment
File Length
Instance Field Naming Convention
Instance Field Visibility
Interface Naming Convention
Large Number of Constructors
Large Number of Fields
Large Number of Methods
Large Number of Parameters
Line Length
Local Variable Naming Convention
Method Javadoc Conventions
Method Naming Convention
Missing Block
Non-terminated Case Clause
Numeric Literals
Package Javadoc
Package Naming Convention
Package Prefix Naming Convention
Parenthesize Condition in Conditional Operator
Questionable Name
Redundant Assignment
Source Length
Space Around Operators
Space Around Periods
String Comparison
Synchronized Method
Type Javadoc Conventions
Use equals() Rather Than ==
Variable Usage
White Space Usage

Details

Block Depth

Severity: Medium

Summary

Methods should be kept fairly flat.

Description

This audit rule finds methods and constructors that have too many levels of nested blocks. A method with too many levels of nested blocks can be difficult to understand. The definition of "too many" can be set.

Example

If the limit is set to two, then the inner if statement in the following would be flagged as a violation:

if (firstChoice == null) { if (secondChoice == null) { if (thirdChoice == null) { return null; } } }

Brace Position

Severity: Low

Summary

Opening and closing braces should be positioned properly.

Description

This audit rule finds opening and closing braces that are incorrectly positioned. By default, opening braces should not appear on a new line and closing braces should appear on a new line. Opening braces for methods and types should appear on a new line.

Example

With the default settings, the opening brace for the following method and the opening brace for the if statement within it would both be flagged as violations:

public int getLength(Object[] array) { if (array == null) { return 0; } return array.length; }

Class Naming Convention

Severity: Medium

Summary

Class names should conform to the defined standard.

Description

This audit rule checks the names of all classes.

Example

If class names are specified as needing to start with an uppercase letter, the following class definition would be flagged as being a violation:

public class remoteDatabase { ... }

Constant Field Naming Convention

Severity: Medium

Summary

Constant names should conform to the defined standard.

Description

This audit rule checks the names of all static fields that are also final.

Example

If constant fields are specified as needing to consist only of uppercase letters and the underscore, the following declaration would be flagged as a violation:

public static final int DefaultCount = 0;

Constructors Only Invoke Final Methods

Severity: Medium

Summary

Constructors should only invoke final methods on the object being constructed.

Description

Subclasses can override non-final methods. Invoking them from a constructor can cause errors because the object is not in a a valid state.

Cyclomatic Complexity

Severity: Medium

Summary

Methods should be kept fairly simple.

Description

This audit rule finds methods, constructors and initializers that are too complex. The complexity is measured by the number of "if", "while", "do", "for", "?:", "catch" and "switch" statements (plus one) in the body of the member.

Example

If the maximum cyclomatic complexity has been configured to be 3, then the following method would be flagged as a violation because it has a cyclomatic complexity of 4:

public int getHireYear() { EmploymentRecord employmentRecord = getEmploymentRecord(); if (employmentRecord == null) return 0; HiringRecord hiringRecord = employmentRecord.getHiringRecord(); if (hiringRecord == null) return 0; Calendar hireDate = hiringRecord.getHireDate(); if (hireDate == null) return 0; return hireDate.getYear(); }

Dangling Else

Severity: Medium

Summary

Use blocks to prevent dangling else clauses.

Description

This audit rule finds places in the code where else clauses are not preceded by a block because these can lead to dangling else errors.

Example

if (a > 0) if (a > 100) b = a - 100; else b = -a;

Empty Catch Clause

Severity: Medium

Summary

Catch clauses should not be empty.

Description

This rule finds places where an exception is caught and nothing is done. It can be configured to allow the existence of a comment to substitute for actual Java code.

Example

try { ... } catch (Exception exception) { }

Empty Finally Clause

Severity: Medium

Summary

Finally clauses should never be empty.

Description

This audit rule finds finally clauses whose block is empty.

Example

try { ... } finally { }

Empty Statement

Severity: High

Summary

Empty statements should never be used.

Description

This audit rule finds places where an empty statement occurs within a control structure. (An empty statement is a semi-colon appearing alone in a place where a statement is allowed). The existence of an empty statement usually indicates a problem, such as a piece of code that was unintentionally removed or a semicolon added in the wrong place.

Example

if (hasBeenAuthenticated); grantSpecialAccess();

Empty Synchronized Statement

Severity: High

Summary

Synchronized statements should never be empty.

Description

This audit rule finds empty synchronized statements.

Example

synchronized (monitor) { }

Explicit "this" Usage

Severity: Medium

Summary

Instance fields should, or should not, be accessed using "this".

Description

This audit rule checks for the explicit usage of the keyword "this" when accessing instance fields. The rule can be configured to always check for the presence or absence of the keyword.

Example

If the rule is configured to disallow using "this" to qualify fields unless necessary, the following expression would be flagged as a violation:

public void incrementCount(int amount) { this.count+= amount; }

Field Javadoc Conventions

Severity: Medium

Summary

All fields should have a Javadoc comment associated with them.

Description

This audit rule checks for the existence of a Javadoc comment for each field. It can be configured to only flag fields with the specified visibilities.

Example

The following field declaration would be flagged as a violation because it does not have a Javadoc comment associated with it:

private String name;

File Comment

Severity: Low

Summary

Compilation units should have a file comment.

Description

This audit rule finds compilation units that do not have a comment as the first element in the file.

Example

A file that begins with a package statement would be flagged as a violation because a comment is expected to appear before anything else.

File Length

Severity: Low

Summary

Compilation units should not be too long.

Description

This audit rule finds compilation units that are longer than a specified number of lines.

Example

If the rule is configured to allow files of up to 40,000 lines, a file containing 100,000 lines of code would be flagged as a violation.

Instance Field Naming Convention

Severity: Medium

Summary

Instance field names should conform to the defined standard.

Description

This audit rule checks the names of all instance fields.

Example

If the rule were configured to only allow instance fields to begin with a lower case letter, the following declaration would be flagged as a violation because it begins with an upper case letter:

private int MaxCount;

Instance Field Visibility

Severity: Medium

Summary

Instance fields should have an appropriate visibility.

Description

This audit rule checks the visibility of all non-static fields to ensure that it is one of the allowed visibilities.

Example

If the rule were configured to only allow private instance fields, then the following field declaration would be flagged as a violation because it is declared as being public:

public int x;

Interface Naming Convention

Severity: Medium

Summary

Interface names should conform to the defined standard.

Description

This audit rule checks the names of all interfaces.

Example

If the rule were configured to require that all interface names start with a capital "I" and another capital letter, the following declaration would be flagged as a violation because the name does not begin with a capital "I":

public interface EventListener { ... }

Large Number of Constructors

Severity: Medium

Summary

Types should not have too many constructors.

Description

This audit rule finds types that have more than the specified number of constructors. Types that exceed this number are likely to be too complex. Consider making some of the constructors more general.

Example

If the rule is configured to allow 3 constructors and a class with 6 constructors is found, that class will be flagged as a violation.

Large Number of Fields

Severity: Medium

Summary

Types should not have too many fields.

Description

This audit rule finds types that have more than the specified number of fields. Types that exceed this number are likely to be too complex. Consider splitting the class into multiple smaller classes.

Example

If the rule is configured to allow 6 fields and a class with 15 fields is found, that class will be flagged as a violation.

Large Number of Methods

Severity: Medium

Summary

Types should not have too many methods.

Description

This audit rule finds types that have more than the specified number of methods. Types that exceed this number are likely to be too complex. Consider splitting the class into multiple smaller classes.

Example

If the rule is configured to allow 20 methods and a class with 114 methods is found, that class will be flagged as a violation.

Large Number of Parameters

Severity: Medium

Summary

Methods should not have too many parameters.

Description

This audit rule finds methods that have more than the specified number of parameters. Methods that exceed this number are likely to be too complex. Consider moving some of the values and behavior associated with them into a separate class.

Example

If the rule is configured to allow 4 parameters and a method with 12 parameters is found, that method will be flagged as a violation.

Line Length

Severity: Low

Summary

Lines should not be too long.

Description

This audit rule checks for lines that are longer than a specified number of characters. By default, each tab character is counted as four spaces.

Example

If the rule were configured to allow lines of up to 120 character and a line were found that contained 253 characters, that line would be flagged as a violation.

Local Variable Naming Convention

Severity: Medium

Summary

Local variable names should conform to the defined standard.

Description

This audit rule checks the names of all local variables (parameters and temporary variables).

Example

If the rule were configured to only allow local variables to begin with a lower case letter, the following would be flagged as a violation because it starts with an underscore:

int _count;

Method Javadoc Conventions

Severity: Medium

Summary

All methods should have a Javadoc comment associated with them.

Description

This audit rule checks for the existence of a Javadoc comment for each method. In addition, it checks that each Javadoc comment includes a @param tag for each parameter (and none for non-parameters), a @return tag if the method has a return type other than void (and not if the return type is void, and a @throws tag for each explicitly declared exception (and none for exceptions that are not declared). It also checks for the use of the obsolete @exception tag.

Example

The Javadoc for the following method would be flagged three times as a violation, twice for missing @param tags and once for a missing @return tag:

/** * Return the sum. */ public int sum(int x, int y) { ... }

Method Naming Convention

Severity: Medium

Summary

Method names should conform to the defined standard.

Description

This audit rule checks the names of all methods.

Example

If the rule were configured to only allow method names that begin with a lower case letter, the following method declaration would be flagged as a violation because the method name begins with an upper case letter:

public static Singleton GetInstance()

Missing Block

Severity: Medium

Summary

A single statement should never be used where a block is allowed.

Description

This audit rule checks for statements that control the execution of another statement (do, for, if or while) to ensure that the statement being controlled is always a block.

Example

if (color == null) color = getDefaultColor();

Non-terminated Case Clause

Severity: Medium

Summary

Case clauses should never fall through into the following case.

Description

This audit rule checks for the existence of either a break, continue, return, or throw statement at the end of each case clause in a switch statement. The lack of either of these statements means that control will fall through to the next case, which is usually not what is intended. It is possible to configure this rule to also accept a user-defined comment (such as "no break") as a signal that the developer knew what was happening.

Example

switch (accountType) { case CHECKING_ACCOUNT: balance = ((CheckingAccount) account).getCheckingBalance(); case SAVINGS_ACCOUNT: balance = ((SavingsAccount) account).getSavingsBalance(); }

Numeric Literals

Severity: Medium

Summary

Numeric literals should not appear in code.

Description

This audit rule checks for numeric literals within the code that are not included in a user-defined list of acceptable literal values. The list initially contains only the values "-1", "0", and "1".

Example

int answer = 42;

Package Javadoc

Severity: Low

Summary

Packages should have Javadoc comments in a file named "/java-dev-tools/codepro/doc/features/audit/package.html".

Description

This audit rule checks all of the packages to ensure that there is a file named "/java-dev-tools/codepro/doc/features/audit/package.html" that can be used by the Javadoc program to create package-level Javadoc information.

Package Naming Convention

Severity: Medium

Summary

Package names should conform to the defined standard.

Description

This audit rule checks the names of all packages as defined by the package declarations at the beginning of each compilation unit.

Example

If the rule has been configured to only allow package names consisting of lower case letters, the package name "utilitiyClasses" would be flagged as a violation because it contains an upper case letter.

Package Prefix Naming Convention

Severity: Medium

Summary

Package names should begin with either a top-level domain name or a two-letter country code.

Description

This audit rule checks the names of all packages as defined by the package declarations at the beginning of each compilation unit to ensure that the first identifier is either a top-level domain name or a two-letter country code.

Example

For example, the following package declaration would be flagged as a violation because "freeware" is neither a top-level domain name nor a two-letter country code:

package freeware.model;

Parenthesize Condition in Conditional Operator

Severity: Low

Summary

The condition in a conditional operator should be parenthesized if it contains a binary operator.

Description

This audit rule looks for uses of the conditional operator in which the condition contains a binary operator but has not been parenthesized.

Example

The following expression would be flagged as a violation because the condition is not parenthesized:

childCount = children == null ? 0 : children.size();

Questionable Name

Severity: High

Summary

Questionable names may indicate sloppy code.

Description

This audit rule checks for questionable names of variables, fields, methods, and types. A questionable name may indicate sloppy code.

Three types of questionable names are flagged:

1. Names that occur in a user-configurable list.

2. Names that are shorter than a user-configurable size. Short names can be useful as for loop variables or in catch clauses so short names are not flagged if they occur in those two places.

3. Names that are longer than a user-configurable size.

Names that you always want to be accepted can be added to a list at the bottom of the preference pane. These names will be accepted whether or not they break any of the 3 rules given above.

Example

The variable "c" would be flagged as a violation in the following method because it is too short, but the variable "i" would not be because it is used as a loop variable:

public int getNonZeroElementCount() { int c;

c = 0; for (int i = 0; i < elements.size(); i++) { ... } return c; }

Redundant Assignment

Severity: High

Summary

Redundant assignments should never be used.

Description

This audit rule checks for the assignment of a variable to itself. This often indicates a missing qualifier, such as "this." for one or the other of the identifiers.

Example

public void setName(String name) { name = name; }

Source Length

Severity: Low

Summary

Methods, constructors and initializers should be limited in length.

Description

This audit rule checks for methods, constructors and initializers that are more that the specified number of lines in length.

Space Around Operators

Severity: Low

Summary

Binary operators should be surrounded by white space.

Description

This audit rule checks for uses of binary operators in which there is no white space on either the left or right side of the operator.

If checked, the "Ignore prefix operators" option causes the audit rule to ignore prefix operators when checking for whitespace violations (e.g. do not flag the expression "(-i)" as a violation).

The "Ignore postfix operators" option is similar (e.g. do not flag the expressions "(i++)" or i++; as violations).

Example

The following arithmetic expression would be flagged twice as a violation, once for the missing space before the operator and again for the missing space after the operator:

index+1

Space Around Periods

Severity: Low

Summary

Periods should not be surrounded by white space.

Description

This audit rule checks for uses of periods (within qualified names) in which there is white space on either the left or right side of the period.

Example

The following method invocation would be flagged twice as a violation, once for the space before the period and again for the space after the period:

point . getX()

String Comparison

Severity: Medium

Summary

Strings should not be compared using equals (==) or not equals (!=).

Description

Strings should always be compared using one of the comparison methods defined for strings. This audit rule looks for comparisons using either the equals (==) or not equals (!=) operators.

Example

String currentName, proposedName;

... if (proposedName != currentName) { ... }

Synchronized Method

Severity: Medium

Summary

Methods should never be marked as synchronized.

Description

This audit rule reports the use of the synchronized modifier with methods. It is too easy to miss the existence of the synchronized modifier, so following this rule leads to more readable code.

Example

public synchronized String getName() { ... }

Type Javadoc Conventions

Severity: Medium

Summary

All types should have a Javadoc comment associated with them.

Description

This audit rule checks for the existence of a Javadoc comment for each type. It optionally checks for the existence of at least one @author tag and always ensures that every author tag has some text following it. It also optionally checks for the existence of at least one @version tag and always ensures that every version tag has some text following it.

Use equals() Rather Than ==

Severity: Medium

Summary

Values should not be compared using equals (==) or not equals (!=).

Description

This audit rule finds places where two values are compared using either the equals (==) or not equals (!=) operators.

Example

The following expression would be flagged as a violation:

if (firstString == secondString) {

because it should be rewritten as:

if (firstString.equals(secondString)) {

Variable Usage

Severity: Medium

Summary

Variables should never shadow variables with the same name that are defined in an outer scope.

Description

This audit rule checks for any declarations of variables that shadow a variable with the same name that is defined in an outer scope.

Example

In a class with a field declaration such as:

private int inventoryCount;

the following parameter would be flagged as a violation:

public void printInventory(int inventoryCount)

White Space Usage

Severity: Low

Summary

Tabs should only be used for indentation, if at all, and spaces and tabs should not both be used.

Description

This audit rule looks for places where space and tab characters are used in ways that violate the specified criteria.

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.