Fix issues found by PMD #70
Annotations
6 errors and 12 warnings
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/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#L118
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#L157
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#L163
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
|
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
|
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
|
Perhaps 'bindingBackgroundImage' could be replaced by a local variable.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/resources/Backgrounds.java#L23
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 'rightPlankImage' could be replaced by a local variable.:
file:///home/runner/work/Susquehanna/Susquehanna/src/main/java/net/oijon/susquehanna/gui/resources/Backgrounds.java#L27
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
|
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/
|
Artifacts
Produced during runtime
Name | Size | |
---|---|---|
PMD Report
|
76 KB |
|