CodeNarc Report

Report title:Sample Project
Date:Mar 5, 2011 10:01:23 PM
Generated with:CodeNarc v0.13

Summary by Package

PackageTotal FilesFiles with ViolationsPriority 1Priority 2Priority 3
All Packages74-95
org/codenarc/sample/domain21-23
org/codenarc/sample/other1----
org/codenarc/sample/service43-72

Package: org.codenarc.sample.domain

➥ SampleDomain.groovy

Rule NamePriorityLine #Source Line / Message
EmptyElseBlock224

[SRC]else {

[MSG]The else block is empty

EmptyIfStatement221

[SRC]if (name) {

[MSG]The if statement is empty

DuplicateImport36

[SRC]import org.codenarc.sample.other.Other

ImportFromSamePackage34

[SRC]import org.codenarc.sample.domain.OtherDomain

UnnecessaryGroovyImport33

[SRC]import java.util.Map

Package: org.codenarc.sample.service

➥ NewService.groovy

Rule NamePriorityLine #Source Line / Message
EmptyForStatement212

[SRC]for(int i=0; i < values.size(); i++) {

[MSG]The for statement is empty

EmptyWhileStatement218

[SRC]while (!values.empty) {

[MSG]The while statement is empty

➥ OtherService.groovy

Rule NamePriorityLine #Source Line / Message
EmptyFinallyBlock213

[SRC]finally {

[MSG]The finally block is empty

EmptyTryBlock210

[SRC]try {

[MSG]The try block is empty

ReturnFromFinallyBlock224

[SRC]return

[MSG]finally statements cannot return a value

➥ SampleService.groovy

Rule NamePriorityLine #Source Line / Message
EmptyCatchBlock220

[SRC]} catch(Throwable t) {

[MSG]The catch block is empty

ThrowExceptionFromFinallyBlock231

[SRC]throw new Exception('bad stuff')

[MSG]Throwing an exception from a finally block can hide an underlieing error

UnnecessaryGroovyImport33

[SRC]import java.util.Map

UnusedImport34

[SRC]import org.codenarc.sample.domain.SampleDomain

Rule Descriptions

#Rule NameDescription
1AddEmptyStringFinds empty string literals which are being added. This is an inefficient way to convert any type to a String.
2AssignmentInConditionalAn assignment operator (=) was used in a conditional test. This is usually a typo, and the comparison operator (==) was intended.
3BigDecimalInstantiationChecks for calls to the BigDecimal constructors that take a double parameter, which may result in an unexpected BigDecimal value.
4BooleanGetBooleanThis 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̈́'].
5BooleanMethodReturnsNullMethod 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.
6BrokenOddnessCheckThe 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.
7CloneableWithoutCloneA class that implements java.lang.Cloneable should define a clone() method.
8CompareToWithoutComparableIf 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.
9ConfusingTernaryIn 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?".
10ConsecutiveLiteralAppendsViolations occur when method calls to append(Object) are chained together with literals as parameters. The chained calls can be joined into one invocation.
11ConsecutiveStringConcatenationCatches concatenation of two string literals on the same line. These can safely by joined.
12ConstantIfExpressionChecks for if statements with a constant value for the if expression, such as true, false, null, or a literal constant value.
13ConstantTernaryExpressionChecks for ternary expressions with a constant value for the boolean expression, such as true, false, null, or a literal constant value.
14DeadCodeDead 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.
15DoubleNegativeThere 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.
16DuplicateCaseStatementCheck for duplicate case statements in a switch block, such as two equal integers or strings.
17DuplicateImportDuplicate import statements are unnecessary.
18EmptyCatchBlockIn most cases, exceptions should not be caught and ignored (swallowed).
19EmptyElseBlockEmpty else blocks are confusing and serve no purpose.
20EmptyFinallyBlockEmpty finally blocks are confusing and serve no purpose.
21EmptyForStatementEmpty for statements are confusing and serve no purpose.
22EmptyIfStatementEmpty if statements are confusing and serve no purpose.
23EmptyInstanceInitializerAn empty class instance initializer was found. It is safe to remove it.
24EmptyMethodA method was found without an implementation. If the method is overriding or implementing a parent method, then mark it with the @Override annotation.
25EmptyStaticInitializerAn empty static initializer was found. It is safe to remove it.
26EmptySwitchStatementEmpty switch statements are confusing and serve no purpose.
27EmptySynchronizedStatementEmpty synchronized statements are confusing and serve no purpose.
28EmptyTryBlockEmpty try blocks are confusing and serve no purpose.
29EmptyWhileStatementEmpty while statements are confusing and serve no purpose.
30EqualsAndHashCodeIf either the boolean equals(Object) or the int hashCode() methods are overridden within a class, then both must be overridden.
31ExplicitArrayListInstantiationThis 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.
32ExplicitCallToAndMethodThis 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
33ExplicitCallToCompareToMethodThis 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.
34ExplicitCallToDivMethodThis 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
35ExplicitCallToEqualsMethodThis 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
36ExplicitCallToGetAtMethodThis 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]
37ExplicitCallToLeftShiftMethodThis 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
38ExplicitCallToMinusMethodThis 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
39ExplicitCallToModMethodThis 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
40ExplicitCallToMultiplyMethodThis 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
41ExplicitCallToOrMethodThis 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
42ExplicitCallToPlusMethodThis 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
43ExplicitCallToPowerMethodThis 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
44ExplicitCallToRightShiftMethodThis 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
45ExplicitCallToXorMethodThis 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
46ExplicitGarbageCollectionCalls 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.
47ExplicitHashMapInstantiationThis 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.
48ExplicitHashSetInstantiationThis 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.
49ExplicitLinkedListInstantiationThis 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.
50ExplicitStackInstantiationThis 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.
51ExplicitTreeSetInstantiationThis 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.
52GStringAsMapKeyA GString should not be used as a map key since its hashcode is not guaranteed to be stable. Consider calling key.toString().
53GroovyLangImmutableThe groovy.lang.Immutable annotation has been deprecated and replaced by groovy.transform.Immutable. Do not use the Immutable in groovy.lang.
54ImportFromSamePackageAn import of a class that is within the same package is unnecessary.
55IntegerGetIntegerThis 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'].
56InvertedIfElseAn 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.
57RemoveAllOnSelfDon'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.
58ReturnFromFinallyBlockReturning from a finally block is confusing and can hide the original exception.
59ReturnsNullInsteadOfEmptyArrayConsider 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.
60ReturnsNullInsteadOfEmptyCollectionConsider 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.
61SerialVersionUIDA 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.
62SerializableClassMustDefineSerialVersionUIDClasses 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.
63SimpleDateFormatMissingLocaleBe 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.
64ThrowExceptionFromFinallyBlockThrowing an exception from a finally block is confusing and can hide the original exception.
65UnnecessaryGroovyImportA 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.
66UnusedImportImports for a class that is never referenced within the source file is unnecessary.