Powered by CodePro and Eclipse
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; } } }
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; }
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 { ... }
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;
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.
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(); }
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;
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) { }
Severity: Medium
Summary
Finally clauses should never be empty.
Description
This audit rule finds finally clauses whose block is empty.
Example
try { ... } finally { }
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();
Severity: High
Summary
Synchronized statements should never be empty.
Description
This audit rule finds empty synchronized statements.
Example
synchronized (monitor) { }
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; }
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;
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.
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.
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;
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;
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 { ... }
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.
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.
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.
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.
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.
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;
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) { ... }
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()
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();
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(); }
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;
Severity: Low
Summary
Packages should have Javadoc comments in a file named "package.html".
Description
This audit rule checks all of the packages to ensure that there is a file named "package.html" that can be used by the Javadoc program to create package-level Javadoc information.
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.
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;
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();
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; }
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; }
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.
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
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()
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) { ... }
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() { ... }
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.
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)) {
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)
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.