preliminary fix #693
carstenarturAnnotations
10 errors and 10 warnings
|
Return an empty collection rather than null.:
sandbox_cleanup_application/src/org/sandbox/jdt/core/cleanupapp/CodeCleanupApplication.java#L273
For any method that returns an collection (such as an array, Collection or Map), it is better to return
an empty one rather than a null reference. This removes the need for null checking all results and avoids
inadvertent NullPointerExceptions.
See Effective Java, 3rd Edition, Item 54: Return empty collections or arrays instead of null
ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull
|
|
Return an empty collection rather than null.:
sandbox_cleanup_application/src/org/sandbox/jdt/core/cleanupapp/CodeCleanupApplication.java#L281
For any method that returns an collection (such as an array, Collection or Map), it is better to return
an empty one rather than a null reference. This removes the need for null checking all results and avoids
inadvertent NullPointerExceptions.
See Effective Java, 3rd Edition, Item 54: Return empty collections or arrays instead of null
ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull
|
|
Return an empty collection rather than null.:
sandbox_cleanup_application/src/org/sandbox/jdt/core/cleanupapp/CodeCleanupApplication.java#L285
For any method that returns an collection (such as an array, Collection or Map), it is better to return
an empty one rather than a null reference. This removes the need for null checking all results and avoids
inadvertent NullPointerExceptions.
See Effective Java, 3rd Edition, Item 54: Return empty collections or arrays instead of null
ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull
|
|
Return an empty collection rather than null.:
sandbox_cleanup_application/src/org/sandbox/jdt/core/cleanupapp/CodeCleanupApplication.java#L323
For any method that returns an collection (such as an array, Collection or Map), it is better to return
an empty one rather than a null reference. This removes the need for null checking all results and avoids
inadvertent NullPointerExceptions.
See Effective Java, 3rd Edition, Item 54: Return empty collections or arrays instead of null
ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull
|
|
The method parameter name 'callee_end' doesn't match '[a-z][a-zA-Z0-9]*':
sandbox_common/src/org/sandbox/jdt/internal/common/ASTProcessor.java#L54
Configurable naming conventions for formal parameters of methods and lambdas.
This rule reports formal parameters which do not match the regex that applies to their
specific kind (e.g. lambda parameter, or final formal parameter). Each regex can be
configured through properties.
By default this rule uses the standard Java naming convention (Camel case).
FormalParameterNamingConventions (Priority: 1, Ruleset: Code Style)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_codestyle.html#formalparameternamingconventions
|
|
The final local variable name 'explicit_encoding' doesn't match '[a-z][a-zA-Z0-9]*':
sandbox_encoding_quickfix/src/org/sandbox/jdt/internal/ui/preferences/cleanup/SandboxCodeTabPage.java#L48
Configurable naming conventions for local variable declarations and other locally-scoped
variables. This rule reports variable declarations which do not match the regex that applies to their
specific kind (e.g. final variable, or catch-clause parameter). Each regex can be configured through
properties.
By default this rule uses the standard Java naming convention (Camel case).
LocalVariableNamingConventions (Priority: 1, Ruleset: Code Style)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_codestyle.html#localvariablenamingconventions
|
|
This class has only private constructors and may be final:
sandbox_extra_search/src/org/sandbox/jdt/internal/ui/search/Messages.java#L5
Reports classes that may be made final because they cannot be extended from outside
their compilation unit anyway. This is because all their constructors are private,
so a subclass could not call the super constructor.
ClassWithOnlyPrivateConstructorsShouldBeFinal (Priority: 1, Ruleset: Design)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_design.html#classwithonlyprivateconstructorsshouldbefinal
|
|
Return an empty collection rather than null.:
sandbox_functional_converter/src/org/sandbox/jdt/internal/corext/fix/helper/PreconditionsChecker.java#L104
For any method that returns an collection (such as an array, Collection or Map), it is better to return
an empty one rather than a null reference. This removes the need for null checking all results and avoids
inadvertent NullPointerExceptions.
See Effective Java, 3rd Edition, Item 54: Return empty collections or arrays instead of null
ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull
|
|
Return an empty collection rather than null.:
sandbox_functional_converter/src/org/sandbox/jdt/internal/corext/fix/helper/PreconditionsChecker.java#L109
For any method that returns an collection (such as an array, Collection or Map), it is better to return
an empty one rather than a null reference. This removes the need for null checking all results and avoids
inadvertent NullPointerExceptions.
See Effective Java, 3rd Edition, Item 54: Return empty collections or arrays instead of null
ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull
|
|
Return an empty collection rather than null.:
sandbox_functional_converter/src/org/sandbox/jdt/internal/corext/fix/helper/ProspectiveOperation.java#L209
For any method that returns an collection (such as an array, Collection or Map), it is better to return
an empty one rather than a null reference. This removes the need for null checking all results and avoids
inadvertent NullPointerExceptions.
See Effective Java, 3rd Edition, Item 54: Return empty collections or arrays instead of null
ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull
|
|
The default label should be the last label in a switch statement or expression:
sandbox_cleanup_application/src/org/sandbox/jdt/core/cleanupapp/CodeCleanupApplication.java#L216
By convention, the default label should be the last label in a switch statement or switch expression.
Note: This rule has been renamed from "DefaultLabelNotLastInSwitchStmt" with PMD 7.7.0.
DefaultLabelNotLastInSwitch (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_bestpractices.html#defaultlabelnotlastinswitch
|
|
Avoid using implementation types like 'LinkedHashMap'; use the interface instead:
sandbox_common/src/org/sandbox/jdt/internal/common/ASTProcessor.java#L68
Excessive coupling to implementation types (e.g., `HashSet`) limits your ability to use alternate
implementations in the future as requirements change. Whenever available, declare variables
and parameters using a more general type (e.g, `Set`).
This rule reports uses of concrete collection types. User-defined types that should be treated
the same as interfaces can be configured with the property `allowedTypes`.
LooseCoupling (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_bestpractices.html#loosecoupling
|
|
Avoid using implementation types like 'LinkedList'; use the interface instead:
sandbox_common/src/org/sandbox/jdt/internal/common/ASTProcessor.java#L74
Excessive coupling to implementation types (e.g., `HashSet`) limits your ability to use alternate
implementations in the future as requirements change. Whenever available, declare variables
and parameters using a more general type (e.g, `Set`).
This rule reports uses of concrete collection types. User-defined types that should be treated
the same as interfaces can be configured with the property `allowedTypes`.
LooseCoupling (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_bestpractices.html#loosecoupling
|
|
Unused import 'org.eclipse.jdt.core.dom.*':
sandbox_common/src/org/sandbox/jdt/internal/common/HelperVisitor.java#L25
Reports import statements that can be removed. They are either unused,
duplicated, or the members they import are already implicitly in scope,
because they're in java.lang, or the current package.
If some imports cannot be resolved, for instance because you run PMD with
an incomplete auxiliary classpath, some imports may be conservatively marked
as used even if they're not to avoid false positives.
UnnecessaryImport (Priority: 4, Ruleset: Code Style)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_codestyle.html#unnecessaryimport
|
|
Avoid using implementation types like 'EnumSet'; use the interface instead:
sandbox_common/src/org/sandbox/jdt/internal/common/HelperVisitor.java#L3472
Excessive coupling to implementation types (e.g., `HashSet`) limits your ability to use alternate
implementations in the future as requirements change. Whenever available, declare variables
and parameters using a more general type (e.g, `Set`).
This rule reports uses of concrete collection types. User-defined types that should be treated
the same as interfaces can be configured with the property `allowedTypes`.
LooseCoupling (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_bestpractices.html#loosecoupling
|
|
Avoid using implementation types like 'EnumSet'; use the interface instead:
sandbox_common/src/org/sandbox/jdt/internal/common/HelperVisitor.java#L3492
Excessive coupling to implementation types (e.g., `HashSet`) limits your ability to use alternate
implementations in the future as requirements change. Whenever available, declare variables
and parameters using a more general type (e.g, `Set`).
This rule reports uses of concrete collection types. User-defined types that should be treated
the same as interfaces can be configured with the property `allowedTypes`.
LooseCoupling (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_bestpractices.html#loosecoupling
|
|
Avoid using implementation types like 'EnumSet'; use the interface instead:
sandbox_common/src/org/sandbox/jdt/internal/common/HelperVisitor.java#L3512
Excessive coupling to implementation types (e.g., `HashSet`) limits your ability to use alternate
implementations in the future as requirements change. Whenever available, declare variables
and parameters using a more general type (e.g, `Set`).
This rule reports uses of concrete collection types. User-defined types that should be treated
the same as interfaces can be configured with the property `allowedTypes`.
LooseCoupling (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_bestpractices.html#loosecoupling
|
|
Unused import 'org.eclipse.jdt.core.dom.*':
sandbox_common/src/org/sandbox/jdt/internal/common/LambdaASTVisitor.java#L20
Reports import statements that can be removed. They are either unused,
duplicated, or the members they import are already implicitly in scope,
because they're in java.lang, or the current package.
If some imports cannot be resolved, for instance because you run PMD with
an incomplete auxiliary classpath, some imports may be conservatively marked
as used even if they're not to avoid false positives.
UnnecessaryImport (Priority: 4, Ruleset: Code Style)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_codestyle.html#unnecessaryimport
|
|
This if statement can be replaced by `return !{condition} || {thenBranch};`:
sandbox_common/src/org/sandbox/jdt/internal/common/LambdaASTVisitor.java#L55
Avoid unnecessary if-then-else statements when returning a boolean. The result of
the conditional test can be returned instead.
SimplifyBooleanReturns (Priority: 3, Ruleset: Design)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_design.html#simplifybooleanreturns
|
|
Useless parentheses.:
sandbox_common/src/org/sandbox/jdt/internal/common/LambdaASTVisitor.java#L56
Parenthesized expressions are used to override the default operator precedence
rules. Parentheses whose removal would not change the relative nesting of operators
are unnecessary, because they don't change the semantics of the enclosing expression.
Some parentheses that strictly speaking are unnecessary, may still be considered useful
for readability. This rule allows to ignore violations on two kinds of unnecessary parentheses:
- "Clarifying" parentheses, which separate operators of difference precedence. While
unnecessary, they make precedence rules explicit, which may be useful for rarely used
operators. For example:
```java
(a + b) & c // is equivalent to `a + b & c`, but probably clearer
```
Unset the property `ignoreClarifying` to report them.
- "Balancing" parentheses, which are unnecessary but visually balance out another pair
of parentheses around an equality operator. For example, those two expressions are equivalent:
```java
(a == null) != (b == null)
a == null != (b == null)
```
The parentheses on the right are required, and the parentheses on the left are
just more visually pleasing. Unset the property `ignoreBalancing` to report them.
UselessParentheses (Priority: 4, Ruleset: Code Style)
https://docs.pmd-code.org/pmd-doc-7.8.0/pmd_rules_java_codestyle.html#uselessparentheses
|
Artifacts
Produced during runtime
| Name | Size | |
|---|---|---|
|
PMD Report
Expired
|
20.7 KB |
|