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

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

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

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

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

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

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

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

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

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

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/

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

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

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

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

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 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 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

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

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

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