Chinese explanation of pmd rules

· ShortVariable: Detects when a field, local, or parameter has a very short name.

Translate short variables: Detected field or parameter names that are very short.

· LongVariable: Detects when a field, formal or local variable is declared with a long name.

Translating long variables: The field or parameter name was detected to be very long.

· ShortMethodName: Detects when very short method names are used.

Translate short method names: Detected that method names are too short.

· 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.

Translate Variable Naming Conventions: Variable Naming Rules - Adjust to your liking. The current rules check that final variables should be in all caps and non-final variables should not contain underscores.

· MethodNamingConventions: Method names should always begin with a lower case character, and should not contain underscores.

Translate method naming conventions: Method names should always start with a lowercase character and should not contain underscores.

· ClassNamingConventions: Class names should always begin with an upper case character.

Translated class naming convention: class names should always start with an uppercase character

· AbstractNaming: Abstract classes should be named ‘AbstractXXX’.

Translate abstract class naming: abstract classes should be named 'AbstractXXX'

· AvoidDollarSigns: Avoid using dollar signs in variable/method/class/interface names.

Translate Avoid Dollar Signs: Avoid dollar signs in variables/methods/classes/interfaces.

· MethodWithSameNameAsEnclosingClass: Non-constructor methods should not have the same name as the enclosing class.

The translation method has the same name as the encapsulation class: non-structural methods cannot have the same name as the encapsulation class

· SuspiciousHashcodeMethodName: The method name and return type are suspiciously close to hashCode(), which may mean you are intending to override the hashCode() method.

Translation of confusing hashCode method name: The method name and return value are similar to hashCode(), which will be misleading as you are trying to override the hashCode() method.

· 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.

Translation of confusing constant field names: All the names of a field are represented by larger characters, which is Sun's JAVA naming rule, indicating that this is a constant. However, fields are not final.

· 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.

Translate confusing equals method name: method name and parameters are similar to equals(Object), it may be confusing that you want to override equals(Object) method

· 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.

Translation avoids attributes and classes with the same name: attributes and classes with the same name are misleading, which may mean that the type or attribute name can be named more precisely

· 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.

Translation avoids attributes and methods with the same name: attributes and methods with the same name are easy to cause misunderstanding. Even though this is perfectly legal, neither the information (properties) nor the actions (methods) are clearly named.

· NoPackage: Detects when a class or interface does not have a package definition.

Translation has no package: Detected that the class or interface is not defined in a package.

· PackageCase: Detects when a package definition contains upper case characters.

Translate package case: package definition containing uppercase characters detected

· MisleadingVariableName: Detects when a non-field has a name starting with ‘m_’. This usually indicates a field and thus is confusing.

Translating confusing variable names: Detecting that a non-field type starts with m_ usually indicates a field so this is confusing.

· BooleanGetMethodName: Looks for methods named ‘getX()’ with ‘boolean’ as the return type. The convention is to name these methods ‘isX()’.

Translation of method names that return Boolean types: It is found that methods that return Boolean types are named 'getX()', and the convention is to name them in the form of 'isX()'.

· AvoidDuplicateLiterals: Code containing duplicate String literals can usually be improved by declaring the String as a constant field.

Translation avoids repeated literals: Code that contains repeated strings can often be refactored to declare this string as a constant

· StringInstantiation: Avoid instantiating String objects; this is usually unnecessary.

Translate string initialization: Avoid initializing string objects; it's unnecessary.

· StringToString: Avoid calling toString() on String objects; this is unnecessary.

Translate String.toString(): Avoid calling the toString() method on String objects, which is unnecessary

· InefficientStringBuffering: Avoid concatenating non literals in a StringBuffer constructor or append().

Translating inefficient StringBuffering: Avoid concatenating non-literal types in StringBuffer's constructor or append() method

· UnnecessaryCaseChange: Using equalsIgnoreCase() is faster than using toUpperCase/toLowerCase().equals()

Translating unnecessary case conversions: Using equalsIgnoreCase() is faster than comparing case-consistent strings.

· UseStringBufferLength: Use StringBuffer.length() to determine StringBuffer length rather than using StringBuffer.toString().equals(“”) or StringBuffer.toString().length() ==.

Translation using StringBuffer's length() method: Use the StringBuffer object's length() method to calculate the length of the StringBuffer object instead of using StringBuffer.toString().equals("") or StringBuffer.toString().length() == .and other methods

· AppendCharacterWithChar: Avoid concatenating characters as strings in StringBuffer.append.

Use the char type to connect characters for translation: Avoid using the string type when using StringBuffer's append() method to connect characters.

· ConsecutiveLiteralAppends: Consecutively calling StringBuffer.append with String literals

Translate continuous literal connection: when connecting strings, call StringBuffer's append() method continuously

· UseIndexOfChar: Use String.indexOf(char) when checking for the index of a single character; it executes faster.

Translation using indexOf(char): When you check the position of a single character use String.indexOf(char), it performs very fast. Do not use indexOf(string)

· InefficientEmptyStringCheck: String.trim().length() is an inefficient way to check if a String is really empty, as it creates a new String object just to check its size. Consider creating a static function that loops through a string, checking Character.isWhitespace() on each character and returning false if a non-whitespace character is found.

Translation inefficient empty string check: It is inefficient to use String.trim().length() to determine whether a string is empty, because it will create a new string object and then determine the size. Consider creating a static method that loops through the String, checks each character with isWhitespace() and returns false if it encounters a non-whitespace character

· InsufficientStringBufferDeclaration: Failing to pre-size a StringBuffer properly could cause it to re-size many times during runtime. This rule checks the characters that are actually passed into StringBuffer.append(), but represents a best guess “worst case” scenario. An empty StringBuffer constructor initializes the object to 16 characters. This default is assumed if the length of the constructor can not be determined.

Inadequately translated StringBuffer declaration: Failure to pre-declare the appropriate size of the StringBuffer capacity may lead to continuous re-allocation of the size at runtime. This rule checks that characters are actually passed to StringBuffer.append(), but indicates a best-case worst-case prediction. A StringBuffer constructor with an empty parameter defaults to initializing the object to a capacity of 16 characters. This default is assumed in cases where the construction length cannot be determined.

· UselessStringValueOf: No need to call String.valueOf to append to a string; just use the valueOf() argument directly.

Translate the useless valueOf method: When calling the append() method, you don’t need to convert the parameters with valueOf() once, and directly put the value of non-String type as a parameter in append().

· StringBufferInstantiationWithChar: StringBuffer sb = new StringBuffer(‘c’); The char will be converted into int to intialize StringBuffer size.

Translate StringBuffer using character initialization: StringBuffer sb = new StringBuffer('c'); The character c will be converted to an int value as the initialization size parameter of StringBuffer.

· UseEqualsToCompareStrings: Using ‘==’ or ‘!=’ to compare strings only works if intern version is used on both sides

Translations use the equals method to compare strings: use '==' or '! ='Comparing string sizes is just comparing references to constant pools on both sides.

· AvoidStringBufferField: StringBuffers can grow quite a lot, and so may become a source of memory leak (if the owning class has a long life time).

Translation Avoid using the StringBuffer attribute in the class: StringBuffer type variables can become very large, so it may cause memory leaks. (if the host class has a long lifetime)

Guess you like

Origin blog.csdn.net/a772304419/article/details/132719318