1 | AddEmptyString | Finds empty string literals which are being added. This is an inefficient way to convert any type to a String. |
2 | AssignmentInConditional | An assignment operator (=) was used in a conditional test. This is usually a typo, and the comparison operator (==) was intended. |
3 | BigDecimalInstantiation | Checks for calls to the BigDecimal constructors that take a double parameter, which may result in an unexpected BigDecimal value. |
4 | BooleanGetBoolean | This rule catches usages of java.lang.Boolean.getBoolean(String) which reads a boolean from the System properties. It is often mistakenly used to attempt to read user input or parse a String into a boolean. It is a poor piece of API to use; replace it with System.properties['propÍ']. |
5 | BooleanMethodReturnsNull | Method with Boolean return type returns explicit null. A method that returns either Boolean.TRUE, Boolean.FALSE or null is an accident waiting to happen. This method can be invoked as though it returned a value of type boolean, and the compiler will insert automatic unboxing of the Boolean value. If a null value is returned, this will result in a NullPointerException. |
6 | BrokenOddnessCheck | The code uses x % 2 == 1 to check to see if a value is odd, but this won't work for negative numbers (e.g., (-5) % 2 == -1). If this code is intending to check for oddness, consider using x & 1 == 1, or x % 2 != 0. |
7 | CloneableWithoutClone | A class that implements java.lang.Cloneable should define a clone() method. |
8 | CompareToWithoutComparable | If you implement a compareTo method then you should also implement the Comparable interface. If you don't then you could possibly get an exception if the Groovy == operator is invoked on your object. This is an issue fixed in Groovy 1.8 but present in previous versions. |
9 | ConfusingTernary | In a ternary expression avoid negation in the test. For example, rephrase: "(x != y) ? diff : same" as: "(x == y) ? same : diff". Consistent use of this rule makes the code easier to read. Also, this resolves trivial ordering problems, such as "does the error case go first?" or "does the common case go first?". |
10 | ConsecutiveLiteralAppends | Violations occur when method calls to append(Object) are chained together with literals as parameters. The chained calls can be joined into one invocation. |
11 | ConsecutiveStringConcatenation | Catches concatenation of two string literals on the same line. These can safely by joined. |
12 | ConstantIfExpression | Checks for if statements with a constant value for the if expression, such as true, false, null, or a literal constant value. |
13 | ConstantTernaryExpression | Checks for ternary expressions with a constant value for the boolean expression, such as true, false, null, or a literal constant value. |
14 | DeadCode | Dead code appears after a return statement or an exception is thrown. If code appears after one of these statements then it will never be executed and can be safely deleted. |
15 | DoubleNegative | There is no point in using a double negative, it is always positive. For instance !!x can always be simplified to x. And !(!x) can as well. |
16 | DuplicateCaseStatement | Check for duplicate case statements in a switch block, such as two equal integers or strings. |
17 | DuplicateImport | Duplicate import statements are unnecessary. |
18 | EmptyCatchBlock | In most cases, exceptions should not be caught and ignored (swallowed). |
19 | EmptyElseBlock | Empty else blocks are confusing and serve no purpose. |
20 | EmptyFinallyBlock | Empty finally blocks are confusing and serve no purpose. |
21 | EmptyForStatement | Empty for statements are confusing and serve no purpose. |
22 | EmptyIfStatement | Empty if statements are confusing and serve no purpose. |
23 | EmptyInstanceInitializer | An empty class instance initializer was found. It is safe to remove it. |
24 | EmptyMethod | A method was found without an implementation. If the method is overriding or implementing a parent method, then mark it with the @Override annotation. |
25 | EmptyStaticInitializer | An empty static initializer was found. It is safe to remove it. |
26 | EmptySwitchStatement | Empty switch statements are confusing and serve no purpose. |
27 | EmptySynchronizedStatement | Empty synchronized statements are confusing and serve no purpose. |
28 | EmptyTryBlock | Empty try blocks are confusing and serve no purpose. |
29 | EmptyWhileStatement | Empty while statements are confusing and serve no purpose. |
30 | EqualsAndHashCode | If either the boolean equals(Object) or the int hashCode() methods are overridden within a class, then both must be overridden. |
31 | ExplicitArrayListInstantiation | This rule checks for the explicit instantiation of an ArrayList using the no-arg constructor. In Groovy, it is best to write new ArrayList() as [], which creates the same object. |
32 | ExplicitCallToAndMethod | This rule detects when the and(Object) method is called directly in code instead of using the & operator. A groovier way to express this: a.and(b) is this: a & b |
33 | ExplicitCallToCompareToMethod | This rule detects when the compareTo(Object) method is called directly in code instead of using the <=>, >, >=, <, and <= operators. A groovier way to express this: a.compareTo(b) is this: a <=> b, or using the other operators. |
34 | ExplicitCallToDivMethod | This rule detects when the div(Object) method is called directly in code instead of using the / operator. A groovier way to express this: a.div(b) is this: a / b |
35 | ExplicitCallToEqualsMethod | This rule detects when the equals(Object) method is called directly in code instead of using the == or != operator. A groovier way to express this: a.equals(b) is this: a == b and a groovier way to express : !a.equals(b) is : a != b |
36 | ExplicitCallToGetAtMethod | This rule detects when the getAt(Object) method is called directly in code instead of using the [] index operator. A groovier way to express this: a.getAt(b) is this: a[b] |
37 | ExplicitCallToLeftShiftMethod | This rule detects when the leftShift(Object) method is called directly in code instead of using the << operator. A groovier way to express this: a.leftShift(b) is this: a << b |
38 | ExplicitCallToMinusMethod | This rule detects when the minus(Object) method is called directly in code instead of using the - operator. A groovier way to express this: a.minus(b) is this: a - b |
39 | ExplicitCallToModMethod | This rule detects when the mod(Object) method is called directly in code instead of using the % operator. A groovier way to express this: a.mod(b) is this: a % b |
40 | ExplicitCallToMultiplyMethod | This rule detects when the minus(Object) method is called directly in code instead of using the * operator. A groovier way to express this: a.multiply(b) is this: a * b |
41 | ExplicitCallToOrMethod | This rule detects when the or(Object) method is called directly in code instead of using the | operator. A groovier way to express this: a.or(b) is this: a | b |
42 | ExplicitCallToPlusMethod | This rule detects when the plus(Object) method is called directly in code instead of using the + operator. A groovier way to express this: a.plus(b) is this: a + b |
43 | ExplicitCallToPowerMethod | This rule detects when the power(Object) method is called directly in code instead of using the ** operator. A groovier way to express this: a.power(b) is this: a ** b |
44 | ExplicitCallToRightShiftMethod | This rule detects when the rightShift(Object) method is called directly in code instead of using the >> operator. A groovier way to express this: a.rightShift(b) is this: a >> b |
45 | ExplicitCallToXorMethod | This rule detects when the xor(Object) method is called directly in code instead of using the ^ operator. A groovier way to express this: a.xor(b) is this: a ^ b |
46 | ExplicitGarbageCollection | Calls to System.gc(), Runtime.getRuntime().gc(), and System.runFinalization() are not advised. Code should have the same behavior whether the garbage collection is disabled using the option -Xdisableexplicitgc or not. Moreover, "modern" jvms do a very good job handling garbage collections. If memory usage issues unrelated to memory leaks develop within an application, it should be dealt with JVM options rather than within the code itself. |
47 | ExplicitHashMapInstantiation | This rule checks for the explicit instantiation of a HashMap using the no-arg constructor. In Groovy, it is best to write new HashMap() as [:], which creates the same object. |
48 | ExplicitHashSetInstantiation | This rule checks for the explicit instantiation of a HashSet using the no-arg constructor. In Groovy, it is best to write new HashSet() as [] as Set, which creates the same object. |
49 | ExplicitLinkedListInstantiation | This rule checks for the explicit instantiation of a LinkedList using the no-arg constructor. In Groovy, it is best to write new LinkedList() as [] as Queue, which creates the same object. |
50 | ExplicitStackInstantiation | This rule checks for the explicit instantiation of a Stack using the no-arg constructor. In Groovy, it is best to write new Stack() as [] as Stack, which creates the same object. |
51 | ExplicitTreeSetInstantiation | This rule checks for the explicit instantiation of a TreeSet using the no-arg constructor. In Groovy, it is best to write new TreeSet() as [] as SortedSet, which creates the same object. |
52 | GStringAsMapKey | A GString should not be used as a map key since its hashcode is not guaranteed to be stable. Consider calling key.toString(). |
53 | GroovyLangImmutable | The groovy.lang.Immutable annotation has been deprecated and replaced by groovy.transform.Immutable. Do not use the Immutable in groovy.lang. |
54 | ImportFromSamePackage | An import of a class that is within the same package is unnecessary. |
55 | IntegerGetInteger | This rule catches usages of java.lang.Integer.getInteger(String, ...) which reads an Integer from the System properties. It is often mistakenly used to attempt to read user input or parse a String into an Integer. It is a poor piece of API to use; replace it with System.properties['prop']. |
56 | InvertedIfElse | An inverted if-else statement is one in which there is a single if statement with a single else branch and the boolean test of the if is negated. For instance if (!x) false else true. It is usually clearer to write this as if (x) true else false. |
57 | RemoveAllOnSelf | Don't use removeAll to clear a collection. If you want to remove all elements from a collection c, use c.clear, not c.removeAll(c). Calling c.removeAll(c) to clear a collection is less clear, susceptible to errors from typos, less efficient and for some collections, might throw a ConcurrentModificationException. |
58 | ReturnFromFinallyBlock | Returning from a finally block is confusing and can hide the original exception. |
59 | ReturnsNullInsteadOfEmptyArray | Consider returning a zero length array rather than null. It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method. |
60 | ReturnsNullInsteadOfEmptyCollection | Consider returning a zero length collection rather than null. It is often a better design to return a length zero collection rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method. |
61 | SerialVersionUID | A serialVersionUID is normally intended to be used with Serialization. It needs to be of type long, static, and final. Also, it should have a visibility modifier such as public or private. Providing no modifier creates a Property and Groovy generates a getter, which is probably not intended. |
62 | SerializableClassMustDefineSerialVersionUID | Classes that implement Serializable should define a serialVersionUID. If you don't define serialVersionUID, the system will make one by hashing most of your class's features. Then if you change anything, the UID will change and Java won't let you reload old data. |
63 | SimpleDateFormatMissingLocale | Be sure to specify a Locale when creating a new instance of SimpleDateFormat; the class is locale-sensitive. If you instantiate SimpleDateFormat without a Locale parameter, it will format the date and time according to the default Locale. Both the pattern and the Locale determine the format. For the same pattern, SimpleDateFormat may format a date and time differently if the Locale varies. |
64 | ThrowExceptionFromFinallyBlock | Throwing an exception from a finally block is confusing and can hide the original exception. |
65 | UnnecessaryGroovyImport | A Groovy file does not need to include an import for classes from java.lang, java.util, java.io, java.net, groovy.lang and groovy.util, as well as the classes java.math.BigDecimal and java.math.BigInteger. |
66 | UnusedImport | Imports for a class that is never referenced within the source file is unnecessary. |