CodeNarc Report

The following document contains the results of CodeNarc Report

CodeNarc Version: 0.18

Report Time: Jan 22, 2013 11:05:54 PM

Summary

Total FilesBug FilesBugsPriority1 BugsPriority2 BugsPriority3 Bugs
000000

Package Summary

PackageTotal FilesBug FilesBugsPriority1 BugsPriority2 BugsPriority3 Bugs

Files

Rule Description

Rule NameDescription
AssertWithinFinallyBlockChecks for assert statements within a finally block. An assert can throw an exception, hiding the original exception, if there is one.
AssignmentInConditionalAn assignment operator (=) was used in a conditional test. This is usually a typo, and the comparison operator (==) was intended.
BigDecimalInstantiationChecks for calls to the BigDecimal constructors that take a double parameter, which may result in an unexpected BigDecimal value.
BitwiseOperatorInConditionalChecks for bitwise operations in conditionals, if you need to do a bitwise operation then it is best practive to extract a temp variable.
BooleanGetBooleanThis 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'].
BrokenNullCheckLooks for faulty checks for null that can cause a NullPointerException.
BrokenOddnessCheckThe 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.
CatchArrayIndexOutOfBoundsExceptionCheck the size of the array before accessing an array element rather than catching ArrayIndexOutOfBoundsException.
CatchErrorCatching Error is dangerous; it can catch exceptions such as ThreadDeath and OutOfMemoryError.
CatchExceptionCatching Exception is often too broad or general. It should usually be restricted to framework or infrastructure code, rather than application code.
CatchIllegalMonitorStateExceptionDubious catching of IllegalMonitorStateException. IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
CatchIndexOutOfBoundsExceptionCheck that an index is valid before accessing an indexed element rather than catching IndexOutOfBoundsException.
CatchNullPointerExceptionCatching NullPointerException is never appropriate. It should be avoided in the first place with proper null checking, and it can mask underlying errors.
CatchRuntimeExceptionCatching RuntimeException is often too broad or general. It should usually be restricted to framework or infrastructure code, rather than application code.
CatchThrowableCatching Throwable is dangerous; it can catch exceptions such as ThreadDeath and OutOfMemoryError.
ClassForNameUsing 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.
ComparisonOfTwoConstantsChecks 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], where x is a variable.
ComparisonWithSelfChecks 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.
ConfusingClassNamedExceptionThis class is not derived from another exception, but ends with 'Exception'. This will be confusing to users of this class.
ConstantAssertExpressionChecks for assert statements where the assert boolean condition expression is a constant or literal value.
ConstantIfExpressionChecks for if statements with a constant value for the if expression, such as true, false, null, or a literal constant value.
ConstantTernaryExpressionChecks for ternary expressions with a constant value for the boolean expression, such as true, false, null, or a literal constant value.
DeadCodeDead 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.
DoubleNegativeThere 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.
DuplicateCaseStatementCheck for duplicate case statements in a switch block, such as two equal integers or strings.
DuplicateImportDuplicate import statements are unnecessary.
DuplicateMapKeyA map literal is created with duplicated key. The map entry will be overwritten.
DuplicateSetValueA Set literal is created with duplicate constant value. A set cannot contain two elements with the same value.
EmptyCatchBlockIn most cases, exceptions should not be caught and ignored (swallowed).
EmptyElseBlockEmpty else blocks are confusing and serve no purpose.
EmptyFinallyBlockEmpty finally blocks are confusing and serve no purpose.
EmptyForStatementEmpty for statements are confusing and serve no purpose.
EmptyIfStatementEmpty if statements are confusing and serve no purpose.
EmptyInstanceInitializerAn empty class instance initializer was found. It is safe to remove it.
EmptyMethodA method was found without an implementation. If the method is overriding or implementing a parent method, then mark it with the @Override annotation.
EmptyStaticInitializerAn empty static initializer was found. It is safe to remove it.
EmptySwitchStatementEmpty switch statements are confusing and serve no purpose.
EmptySynchronizedStatementEmpty synchronized statements are confusing and serve no purpose.
EmptyTryBlockEmpty try blocks are confusing and serve no purpose.
EmptyWhileStatementEmpty while statements are confusing and serve no purpose.
EqualsAndHashCodeIf either the equals(Object) or the hashCode() methods are overridden within a class, then both must be overridden.
EqualsOverloadedThe 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.
ExceptionExtendsErrorErrors are system exceptions. Do not extend them.
ExceptionNotThrownChecks for an exception constructor call without a throw as the last statement within a catch block.
ExplicitGarbageCollectionCalls 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.
ForLoopShouldBeWhileLoopA for loop without an init and update statement can be simplified to a while loop.
HardCodedWindowsFileSeparatorThis 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.
HardCodedWindowsRootDirectoryThis 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.
ImportFromSamePackageAn import of a class that is within the same package is unnecessary.
ImportFromSunPackagesAvoid importing anything from the 'sun.*' packages. These packages are not portable and are likely to change.
IntegerGetIntegerThis 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'].
MisorderedStaticImportsStatic imports should never be declared after nonstatic imports.
MissingNewInThrowStatementA common Groovy mistake when throwing exceptions is to forget the new keyword. For instance, "throw RuntimeException()" instead of "throw new RuntimeException()". If the error path is not unit tested then the production system will throw a Method Missing exception and hide the root cause. This rule finds constructs like "throw RuntimeException()" that look like a new keyword was meant to be used but forgotten.
RandomDoubleCoercedToZeroThe 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.
RemoveAllOnSelfDon'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.
ReturnFromFinallyBlockReturning from a finally block is confusing and can hide the original exception.
ReturnNullFromCatchBlockReturning null from a catch block often masks errors and requires the client to handle error codes. In some coding styles this is discouraged.
SwallowThreadDeathChecks for code that catches ThreadDeath without re-throwing it.
ThrowErrorChecks for throwing an instance of java.lang.Error.
ThrowExceptionChecks for throwing an instance of java.lang.Exception.
ThrowExceptionFromFinallyBlockThrowing an exception from a finally block is confusing and can hide the original exception.
ThrowNullPointerExceptionChecks for throwing an instance of java.lang.NullPointerException.
ThrowRuntimeExceptionChecks for throwing an instance of java.lang.RuntimeException.
ThrowThrowableChecks for throwing an instance of java.lang.Throwable.
UnnecessaryGroovyImportA 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.
UnusedImportImports for a class that is never referenced within the source file is unnecessary.