CodeNarc Report

Report title:Sample Project
Date:Dec 17, 2013 6:16:36 PM
Generated with:CodeNarc v0.20

Summary by Package

PackageTotal FilesFiles with ViolationsPriority 1Priority 2Priority 3
All Packages105--7
<Root>72--2
io33--5

Package: <Root>

➥ PropertyUtilTest.groovy

Rule NamePriorityLine #Source Line / Message
MisorderedStaticImports322

[SRC]import static org.codenarc.test.TestUtil.shouldFail

[MSG]Static imports should appear before normal imports

➥ SourceCodeUtilTest.groovy

Rule NamePriorityLine #Source Line / Message
MisorderedStaticImports327

[SRC]import static org.codenarc.test.TestUtil.shouldFail

[MSG]Static imports should appear before normal imports

Package: io

➥ ClassPathResourceTest.groovy

Rule NamePriorityLine #Source Line / Message
MisorderedStaticImports321

[SRC]import static org.codenarc.test.TestUtil.shouldFail

[MSG]Static imports should appear before normal imports

MisorderedStaticImports322

[SRC]import static org.codenarc.test.TestUtil.shouldFailWithM..geContaining

[MSG]Static imports should appear before normal imports

➥ DefaultResourceFactoryTest.groovy

Rule NamePriorityLine #Source Line / Message
MisorderedStaticImports322

[SRC]import static org.codenarc.test.TestUtil.shouldFailWithM..geContaining

[MSG]Static imports should appear before normal imports

➥ UrlResourceTest.groovy

Rule NamePriorityLine #Source Line / Message
MisorderedStaticImports321

[SRC]import static org.codenarc.test.TestUtil.shouldFail

[MSG]Static imports should appear before normal imports

MisorderedStaticImports322

[SRC]import static org.codenarc.test.TestUtil.shouldFailWithM..geContaining

[MSG]Static imports should appear before normal imports

Rule Descriptions

#Rule NameDescription
1AssertWithinFinallyBlockChecks for assert statements within a finally block. An assert can throw an exception, hiding the original exception, if there is one.
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.
4BitwiseOperatorInConditionalChecks for bitwise operations in conditionals, if you need to do a bitwise operation then it is best practive to extract a temp variable.
5BooleanGetBooleanThis 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'].
6BrokenNullCheckLooks for faulty checks for null that can cause a NullPointerException.
7BrokenOddnessCheckThe 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.
8ClassForNameUsing Class.forName(...) is a common way to add dynamic behavior to a system. However, using this method can cause resource leaks because the classes can be pinned in memory for long periods of time.
9ComparisonOfTwoConstantsChecks for expressions where a comparison operator or equals() or compareTo() is used to compare two constants to each other or two literals that contain only constant values., e.g.: 23 == 67, Boolean.FALSE != false, 0.17 <= 0.99, "abc" > "ddd", [a:1] <=> [a:2], [1,2].equals([3,4]) or [a:false, b:true].compareTo(['a':34.5, b:Boolean.TRUE].
10ComparisonWithSelfChecks for expressions where a comparison operator or equals() or compareTo() is used to compare a variable to itself, e.g.: x == x, x != x, x <=> x, x < x, x =>= x, x.equals(x) or x.compareTo(x), where x is a variable.
11ConstantAssertExpressionChecks for assert statements where the assert boolean condition expression is a constant or literal value.
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.
18DuplicateMapKeyA map literal is created with duplicated key. The map entry will be overwritten.
19DuplicateSetValueA Set literal is created with duplicate constant value. A set cannot contain two elements with the same value.
20EmptyCatchBlockIn most cases, exceptions should not be caught and ignored (swallowed).
21EmptyClassReports classes without methods, fields or properties. Why would you need a class like this?
22EmptyElseBlockEmpty else blocks are confusing and serve no purpose.
23EmptyFinallyBlockEmpty finally blocks are confusing and serve no purpose.
24EmptyForStatementEmpty for statements are confusing and serve no purpose.
25EmptyIfStatementEmpty if statements are confusing and serve no purpose.
26EmptyInstanceInitializerAn empty class instance initializer was found. It is safe to remove it.
27EmptyMethodA method was found without an implementation. If the method is overriding or implementing a parent method, then mark it with the @Override annotation.
28EmptyStaticInitializerAn empty static initializer was found. It is safe to remove it.
29EmptySwitchStatementEmpty switch statements are confusing and serve no purpose.
30EmptySynchronizedStatementEmpty synchronized statements are confusing and serve no purpose.
31EmptyTryBlockEmpty try blocks are confusing and serve no purpose.
32EmptyWhileStatementEmpty while statements are confusing and serve no purpose.
33EqualsAndHashCodeIf either the boolean equals(Object) or the int hashCode() methods are overridden within a class, then both must be overridden.
34EqualsOverloadedThe class has an equals method, but the parameter of the method is not of type Object. It is not overriding equals but instead overloading it.
35ExplicitGarbageCollectionCalls 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.
36ForLoopShouldBeWhileLoopA for loop without an init and update statement can be simplified to a while loop.
37HardCodedWindowsFileSeparatorThis rule finds usages of a Windows file separator within the constructor call of a File object. It is better to use the Unix file separator or use the File.separator constant.
38HardCodedWindowsRootDirectoryThis rule find cases where a File object is constructed with a windows-based path. This is not portable, and using the File.listRoots() method is a better alternative.
39ImportFromSamePackageAn import of a class that is within the same package is unnecessary.
40ImportFromSunPackagesAvoid importing anything from the 'sun.*' packages. These packages are not portable and are likely to change.
41IntegerGetIntegerThis 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'].
42MisorderedStaticImportsStatic imports should never be declared after nonstatic imports.
43RandomDoubleCoercedToZeroThe Math.random() method returns a double result greater than or equal to 0.0 and less than 1.0. If you coerce this result into an Integer or int, then it is coerced to zero. Casting the result to int, or assigning it to an int field is probably a bug.
44RemoveAllOnSelfDon'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.
45ReturnFromFinallyBlockReturning from a finally block is confusing and can hide the original exception.
46ThrowExceptionFromFinallyBlockThrowing an exception from a finally block is confusing and can hide the original exception.
47UnnecessaryGroovyImportA 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.
48UnusedImportImports for a class that is never referenced within the source file is unnecessary.