This is the fourteenth installment of explanation of PMD rules covering Naming Rules. This covers details of how the variables, classes, packages should be named to follow a standard pattern.
Naming Rules
The Naming Ruleset contains a collection of rules about names - too long, too short, and so forth.
ShortVariable
Detects when a field, local, or parameter has a very short name. It is preferable to avoid variables like “I” “j” “k” as it reduces the understandability of the code. Using proper names makes it easier to understand the purpose of the variable. Although it is OK to use such variables for looping, it can get confusing if one has nested looping.
Example
LongVariable
Detects when a field, formal or local variable is declared with a long name.
Example
ShortMethodName
Detects when very short method names are used. Similar to variables methods should have meaningful names.
Example
VariableNamingConventions
A variable naming conventions rule - customize this to your liking. Currently, it checks for final variables that should be fully capitalized and non-final variables that should not include underscores.
Example
MethodNamingConventions
Method names should always begin with a lower case character, and should not contain underscores.
Example
ClassNamingConventions
Class names should always begin with an upper case character.
Example
AbstractNaming
Abstract classes should be named 'AbstractXXX'.
Example
AvoidDollarSigns
Avoid using dollar signs in variable/method/class/interface names.
Example
MethodWithSameNameAsEnclosingClass
Non-constructor methods should not have the same name as the enclosing class.
Example
SuspiciousHashcodeMethodName
The method name and return type are suspiciously close to hashCode(), which may mean you are intending to override the hashCode() method.
Example
SuspiciousConstantFieldName
A field name is all in uppercase characters, which in Sun's Java naming conventions indicate a constant. However, the field is not final.
Example
SuspiciousEqualsMethodName
The method name and parameter number are suspiciously close to equals(Object), which may mean you are intending to override the equals(Object) method.
Example
AvoidFieldNameMatchingTypeName
It is somewhat confusing to have a field name matching the declaring class name. This probably means that type and or field names could be more precise.
Example
AvoidFieldNameMatchingMethodName
It is somewhat confusing to have a field name with the same name as a method. While this is totally legal, having information (field) and actions (method) is not clear naming.
Example
NoPackage
Detects when a class or interface does not have a package definition.
Example
PackageCase
Detects when a package definition contains upper case characters.
Example
MisleadingVariableName
Detects when a non-field has a name starting with 'm_'. This usually indicates a field and thus is confusing.
Example
BooleanGetMethodName
Looks for methods named 'getX()' with 'boolean' as the return type. The convention is to name these methods 'isX()'.
Example
Naming Rules
The Naming Ruleset contains a collection of rules about names - too long, too short, and so forth.ShortVariable
Detects when a field, local, or parameter has a very short name. It is preferable to avoid variables like “I” “j” “k” as it reduces the understandability of the code. Using proper names makes it easier to understand the purpose of the variable. Although it is OK to use such variables for looping, it can get confusing if one has nested looping.Example
public class Something {
private int q = 15; // VIOLATION - Field
public static void main( String as[] ) { // VIOLATION - Formal
int r = 20 + q; // VIOLATION - Local
for (int i = 0; i < 10; i++) { // Not a Violation (inside FOR)
r += q;
}
}
}
LongVariable
Detects when a field, formal or local variable is declared with a long name.Example
public class Something {
int reallyLongIntName = -3; // VIOLATION - Field
public static void main( String argumentsList[] ) { // VIOLATION - Formal
int otherReallyLongName = -5; // VIOLATION - Local
for (int interestingIntIndex = 0; // VIOLATION - For
interestingIntIndex < 10;
interestingIntIndex ++ ) {
}
}
ShortMethodName
Detects when very short method names are used. Similar to variables methods should have meaningful names.Example
public class ShortMethod {
public void a( int i ) { // Violation
}
}
VariableNamingConventions
A variable naming conventions rule - customize this to your liking. Currently, it checks for final variables that should be fully capitalized and non-final variables that should not include underscores.Example
public class Foo {
public static final int MY_NUM = 0;
public String myTest = "";
DataModule dmTest = new DataModule();
}
MethodNamingConventions
Method names should always begin with a lower case character, and should not contain underscores.Example
public class Foo {
public void fooStuff() {
}
}
ClassNamingConventions
Class names should always begin with an upper case character.Example
public class Foo {}
AbstractNaming
Abstract classes should be named 'AbstractXXX'.Example
public abstract class Foo { // should be AbstractFoo
}
AvoidDollarSigns
Avoid using dollar signs in variable/method/class/interface names.Example
public class Fo$o { // yikes!
}
MethodWithSameNameAsEnclosingClass
Non-constructor methods should not have the same name as the enclosing class.Example
public class MyClass {
// this is bad because it is a method
public void MyClass() {}
// this is OK because it is a constructor
public MyClass() {}
}
SuspiciousHashcodeMethodName
The method name and return type are suspiciously close to hashCode(), which may mean you are intending to override the hashCode() method.Example
public class Foo {
public int hashcode() {
// oops, this probably was supposed to be hashCode
}
}
SuspiciousConstantFieldName
A field name is all in uppercase characters, which in Sun's Java naming conventions indicate a constant. However, the field is not final.Example
public class Foo {
// this is bad, since someone could accidentally
// do PI = 2.71828; which is actualy e
// final double PI = 3.16; is ok
double PI = 3.16;
}
SuspiciousEqualsMethodName
The method name and parameter number are suspiciously close to equals(Object), which may mean you are intending to override the equals(Object) method.Example
public class Foo {
public int equals(Object o) {
// oops, this probably was supposed to be boolean equals
}
public boolean equals(String s) {
// oops, this probably was supposed to be equals(Object)
}
}
AvoidFieldNameMatchingTypeName
It is somewhat confusing to have a field name matching the declaring class name. This probably means that type and or field names could be more precise.Example
public class Foo extends Bar {
// There's probably a better name for foo
int foo;
}
AvoidFieldNameMatchingMethodName
It is somewhat confusing to have a field name with the same name as a method. While this is totally legal, having information (field) and actions (method) is not clear naming.Example
public class Foo {
Object bar;
// bar is data or an action or both?
void bar() {
}
}
NoPackage
Detects when a class or interface does not have a package definition.Example
// no package declaration
public class ClassInDefaultPackage {
}
PackageCase
Detects when a package definition contains upper case characters.Example
package com.MyCompany; // <- should be lower case name
public class SomeClass {
}
MisleadingVariableName
Detects when a non-field has a name starting with 'm_'. This usually indicates a field and thus is confusing.Example
public class Foo {
private int m_foo; // OK
public void bar(String m_baz) { // Bad
int m_boz = 42; // Bad
}
}
BooleanGetMethodName
Looks for methods named 'getX()' with 'boolean' as the return type. The convention is to name these methods 'isX()'.Example
public boolean getFoo(); // bad
public boolean isFoo(); // ok
public boolean getFoo(boolean bar); // ok, unless checkParameterizedMethods=true
No comments:
Post a Comment