Fix issues found by PMD #65
Annotations
10 errors and 12 warnings
The local variable name 'IPA' doesn't match '[a-z][a-zA-Z0-9]*':
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/App.java#L66
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.5.0/pmd_rules_java_codestyle.html#localvariablenamingconventions
|
The local variable name 'IPAFile' doesn't match '[a-z][a-zA-Z0-9]*':
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/App.java#L68
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.5.0/pmd_rules_java_codestyle.html#localvariablenamingconventions
|
Logger calls should be surrounded by log level guards.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/App.java#L113
Whenever using a log level, one should check if it is actually enabled, or
otherwise skip the associate String creation and manipulation, as well as any method calls.
An alternative to checking the log level are substituting parameters, formatters or lazy logging
with lambdas. The available alternatives depend on the actual logging framework.
GuardLogStatement (Priority: 2, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#guardlogstatement
|
Logger calls should be surrounded by log level guards.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/LoadingScreen.java#L40
Whenever using a log level, one should check if it is actually enabled, or
otherwise skip the associate String creation and manipulation, as well as any method calls.
An alternative to checking the log level are substituting parameters, formatters or lazy logging
with lambdas. The available alternatives depend on the actual logging framework.
GuardLogStatement (Priority: 2, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#guardlogstatement
|
Logger calls should be surrounded by log level guards.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/LoadingScreen.java#L60
Whenever using a log level, one should check if it is actually enabled, or
otherwise skip the associate String creation and manipulation, as well as any method calls.
An alternative to checking the log level are substituting parameters, formatters or lazy logging
with lambdas. The available alternatives depend on the actual logging framework.
GuardLogStatement (Priority: 2, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#guardlogstatement
|
Logger calls should be surrounded by log level guards.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/scenes/file/AddLangPage.java#L46
Whenever using a log level, one should check if it is actually enabled, or
otherwise skip the associate String creation and manipulation, as well as any method calls.
An alternative to checking the log level are substituting parameters, formatters or lazy logging
with lambdas. The available alternatives depend on the actual logging framework.
GuardLogStatement (Priority: 2, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#guardlogstatement
|
Logger calls should be surrounded by log level guards.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/scenes/file/OpenLangPage.java#L57
Whenever using a log level, one should check if it is actually enabled, or
otherwise skip the associate String creation and manipulation, as well as any method calls.
An alternative to checking the log level are substituting parameters, formatters or lazy logging
with lambdas. The available alternatives depend on the actual logging framework.
GuardLogStatement (Priority: 2, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#guardlogstatement
|
Logger calls should be surrounded by log level guards.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/scenes/file/OpenLangPage.java#L60
Whenever using a log level, one should check if it is actually enabled, or
otherwise skip the associate String creation and manipulation, as well as any method calls.
An alternative to checking the log level are substituting parameters, formatters or lazy logging
with lambdas. The available alternatives depend on the actual logging framework.
GuardLogStatement (Priority: 2, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#guardlogstatement
|
Logger calls should be surrounded by log level guards.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/scenes/file/OpenLangPage.java#L116
Whenever using a log level, one should check if it is actually enabled, or
otherwise skip the associate String creation and manipulation, as well as any method calls.
An alternative to checking the log level are substituting parameters, formatters or lazy logging
with lambdas. The available alternatives depend on the actual logging framework.
GuardLogStatement (Priority: 2, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#guardlogstatement
|
Logger calls should be surrounded by log level guards.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/scenes/file/OpenLangPage.java#L155
Whenever using a log level, one should check if it is actually enabled, or
otherwise skip the associate String creation and manipulation, as well as any method calls.
An alternative to checking the log level are substituting parameters, formatters or lazy logging
with lambdas. The available alternatives depend on the actual logging framework.
GuardLogStatement (Priority: 2, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#guardlogstatement
|
Deprecation notice: v1, v2, and v3 of the artifact actions
The following artifacts were uploaded using a version of actions/upload-artifact that is scheduled for deprecation: "PMD Report".
Please update your workflow to use v4 of the artifact actions.
Learn more: https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/
|
pmd-code-scan
The following actions use a deprecated Node.js version and will be forced to run on node20: pmd/pmd-github-action@d57c0463ebba262a33d1983a5c6ac6031bfde43b. For more info: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/
|
Avoid using implementation types like 'ArrayList'; use the interface instead:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/App.java#L48
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.5.0/pmd_rules_java_bestpractices.html#loosecoupling
|
Avoid using implementation types like 'ArrayList'; use the interface instead:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/App.java#L146
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.5.0/pmd_rules_java_bestpractices.html#loosecoupling
|
This utility class has a non-private constructor:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/Launcher.java#L8
For classes that only have static methods, consider making them utility classes.
Note that this doesn't apply to abstract classes, since their subclasses may
well include non-static methods. Also, if you want this class to be a utility class,
remember to add a private constructor to prevent instantiation.
(Note, that this use was known before PMD 5.1.0 as UseSingleton).
UseUtilityClass (Priority: 3, Ruleset: Design)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_design.html#useutilityclass
|
Avoid using implementation types like 'ArrayList'; use the interface instead:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/components/BinderTab.java#L33
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.5.0/pmd_rules_java_bestpractices.html#loosecoupling
|
Avoid unused method parameters such as 'pt'.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/components/PhonemeEditPopup.java#L33
Reports parameters of methods and constructors that are not referenced them in the method body.
Parameters whose name starts with `ignored` or `unused` are filtered out.
Removing unused formal parameters from public methods could cause a ripple effect through the code base.
Hence, by default, this rule only considers private methods. To include non-private methods, set the
`checkAll` property to `true`.
UnusedFormalParameter (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#unusedformalparameter
|
Position literals first in String comparisons:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/components/PhonemeKeyboard.java#L41
Position literals first in all String comparisons, if the second argument is null then NullPointerExceptions
can be avoided, they will just return false. Note that switching literal positions for compareTo and
compareToIgnoreCase may change the result, see examples.
LiteralsFirstInComparisons (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#literalsfirstincomparisons
|
Position literals first in String comparisons:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/components/PhonemeKeyboard.java#L41
Position literals first in all String comparisons, if the second argument is null then NullPointerExceptions
can be avoided, they will just return false. Note that switching literal positions for compareTo and
compareToIgnoreCase may change the result, see examples.
LiteralsFirstInComparisons (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_bestpractices.html#literalsfirstincomparisons
|
Avoid using implementation types like 'ArrayList'; use the interface instead:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/components/ToolButton.java#L52
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.5.0/pmd_rules_java_bestpractices.html#loosecoupling
|
Perhaps 'defaultFill' could be replaced by a local variable.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/resources/Backgrounds.java#L18
Reports fields which may be converted to a local variable. This is so because
in every method where the field is used, it is assigned before it is first read.
Hence, the value that the field had before the method call may not be observed,
so it might as well not be stored in the enclosing object.
Limitations:
* We can only check private fields for now.
* The rule is not aware of threading, so it may cause false positives in concurrent code.
Such FPs are best handled by suppression (see also the `ignoredAnnotations` property).
SingularField (Priority: 3, Ruleset: Design)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_design.html#singularfield
|
Perhaps 'plankImage' could be replaced by a local variable.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/resources/Backgrounds.java#L19
Reports fields which may be converted to a local variable. This is so because
in every method where the field is used, it is assigned before it is first read.
Hence, the value that the field had before the method call may not be observed,
so it might as well not be stored in the enclosing object.
Limitations:
* We can only check private fields for now.
* The rule is not aware of threading, so it may cause false positives in concurrent code.
Such FPs are best handled by suppression (see also the `ignoredAnnotations` property).
SingularField (Priority: 3, Ruleset: Design)
https://docs.pmd-code.org/pmd-doc-7.5.0/pmd_rules_java_design.html#singularfield
|
Artifacts
Produced during runtime
Name | Size | |
---|---|---|
PMD Report
|
82.1 KB |
|