Add interactive console menu system for data structure demonstrations #7
Annotations
5 errors and 10 warnings
|
The local variable name 'T' doesn't match '[a-z][a-zA-Z0-9]*':
src/main/java/org/dsa/structure/tree/bst/bbt/AVL.java#L123
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/snapshot/pmd_rules_java_codestyle.html#localvariablenamingconventions
|
|
The local variable name 'T' doesn't match '[a-z][a-zA-Z0-9]*':
src/main/java/org/dsa/structure/tree/bst/bbt/AVL.java#L113
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/snapshot/pmd_rules_java_codestyle.html#localvariablenamingconventions
|
|
The instance method name '_inorderTraversal' doesn't match '[a-z][a-zA-Z0-9]*':
src/main/java/org/dsa/structure/tree/bst/BinarySearchTree.java#L54
Configurable naming conventions for method declarations. This rule reports
method declarations which do not match the regex that applies to their
specific kind (e.g. JUnit test or native method). Each regex can be
configured through properties.
By default, this rule uses the standard Java naming convention (Camel case).
MethodNamingConventions (Priority: 1, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#methodnamingconventions
|
|
The instance method name '_searchRecursive' doesn't match '[a-z][a-zA-Z0-9]*':
src/main/java/org/dsa/structure/tree/bst/BinarySearchTree.java#L38
Configurable naming conventions for method declarations. This rule reports
method declarations which do not match the regex that applies to their
specific kind (e.g. JUnit test or native method). Each regex can be
configured through properties.
By default, this rule uses the standard Java naming convention (Camel case).
MethodNamingConventions (Priority: 1, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#methodnamingconventions
|
|
The instance method name '_insertRecursive' doesn't match '[a-z][a-zA-Z0-9]*':
src/main/java/org/dsa/structure/tree/bst/BinarySearchTree.java#L22
Configurable naming conventions for method declarations. This rule reports
method declarations which do not match the regex that applies to their
specific kind (e.g. JUnit test or native method). Each regex can be
configured through properties.
By default, this rule uses the standard Java naming convention (Camel case).
MethodNamingConventions (Priority: 1, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#methodnamingconventions
|
|
This statement should have braces:
src/main/java/org/dsa/Main.java#L174
Enforce a policy for braces on control statements. It is recommended to use braces on 'if ... else'
statements and loop statements, even if they are optional. This usually makes the code clearer, and
helps prepare the future when you need to add another statement. That said, this rule lets you control
which statements are required to have braces via properties.
From 6.2.0 on, this rule supersedes WhileLoopMustUseBraces, ForLoopMustUseBraces, IfStmtMustUseBraces,
and IfElseStmtMustUseBraces.
ControlStatementBraces (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#controlstatementbraces
|
|
This statement should have braces:
src/main/java/org/dsa/Main.java#L171
Enforce a policy for braces on control statements. It is recommended to use braces on 'if ... else'
statements and loop statements, even if they are optional. This usually makes the code clearer, and
helps prepare the future when you need to add another statement. That said, this rule lets you control
which statements are required to have braces via properties.
From 6.2.0 on, this rule supersedes WhileLoopMustUseBraces, ForLoopMustUseBraces, IfStmtMustUseBraces,
and IfElseStmtMustUseBraces.
ControlStatementBraces (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#controlstatementbraces
|
|
Switch statements or expressions should be exhaustive, add a default case (or missing enum branches):
src/main/java/org/dsa/Main.java#L148
Switch statements should be exhaustive, to make their control flow
easier to follow. This can be achieved by adding a `default` case, or,
if the switch is on an enum type, by ensuring there is one switch branch
for each enum constant.
This rule doesn't consider Switch Statements, that use Pattern Matching, since for these the
compiler already ensures that all cases are covered. The same is true for Switch Expressions,
which are also not considered by this rule.
NonExhaustiveSwitch (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/snapshot/pmd_rules_java_bestpractices.html#nonexhaustiveswitch
|
|
This statement should have braces:
src/main/java/org/dsa/Main.java#L145
Enforce a policy for braces on control statements. It is recommended to use braces on 'if ... else'
statements and loop statements, even if they are optional. This usually makes the code clearer, and
helps prepare the future when you need to add another statement. That said, this rule lets you control
which statements are required to have braces via properties.
From 6.2.0 on, this rule supersedes WhileLoopMustUseBraces, ForLoopMustUseBraces, IfStmtMustUseBraces,
and IfElseStmtMustUseBraces.
ControlStatementBraces (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#controlstatementbraces
|
|
Switch statements or expressions should be exhaustive, add a default case (or missing enum branches):
src/main/java/org/dsa/Main.java#L120
Switch statements should be exhaustive, to make their control flow
easier to follow. This can be achieved by adding a `default` case, or,
if the switch is on an enum type, by ensuring there is one switch branch
for each enum constant.
This rule doesn't consider Switch Statements, that use Pattern Matching, since for these the
compiler already ensures that all cases are covered. The same is true for Switch Expressions,
which are also not considered by this rule.
NonExhaustiveSwitch (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/snapshot/pmd_rules_java_bestpractices.html#nonexhaustiveswitch
|
|
This statement should have braces:
src/main/java/org/dsa/Main.java#L117
Enforce a policy for braces on control statements. It is recommended to use braces on 'if ... else'
statements and loop statements, even if they are optional. This usually makes the code clearer, and
helps prepare the future when you need to add another statement. That said, this rule lets you control
which statements are required to have braces via properties.
From 6.2.0 on, this rule supersedes WhileLoopMustUseBraces, ForLoopMustUseBraces, IfStmtMustUseBraces,
and IfElseStmtMustUseBraces.
ControlStatementBraces (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#controlstatementbraces
|
|
Switch statements or expressions should be exhaustive, add a default case (or missing enum branches):
src/main/java/org/dsa/Main.java#L92
Switch statements should be exhaustive, to make their control flow
easier to follow. This can be achieved by adding a `default` case, or,
if the switch is on an enum type, by ensuring there is one switch branch
for each enum constant.
This rule doesn't consider Switch Statements, that use Pattern Matching, since for these the
compiler already ensures that all cases are covered. The same is true for Switch Expressions,
which are also not considered by this rule.
NonExhaustiveSwitch (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/snapshot/pmd_rules_java_bestpractices.html#nonexhaustiveswitch
|
|
This statement should have braces:
src/main/java/org/dsa/Main.java#L89
Enforce a policy for braces on control statements. It is recommended to use braces on 'if ... else'
statements and loop statements, even if they are optional. This usually makes the code clearer, and
helps prepare the future when you need to add another statement. That said, this rule lets you control
which statements are required to have braces via properties.
From 6.2.0 on, this rule supersedes WhileLoopMustUseBraces, ForLoopMustUseBraces, IfStmtMustUseBraces,
and IfElseStmtMustUseBraces.
ControlStatementBraces (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#controlstatementbraces
|
|
Switch statements or expressions should be exhaustive, add a default case (or missing enum branches):
src/main/java/org/dsa/Main.java#L46
Switch statements should be exhaustive, to make their control flow
easier to follow. This can be achieved by adding a `default` case, or,
if the switch is on an enum type, by ensuring there is one switch branch
for each enum constant.
This rule doesn't consider Switch Statements, that use Pattern Matching, since for these the
compiler already ensures that all cases are covered. The same is true for Switch Expressions,
which are also not considered by this rule.
NonExhaustiveSwitch (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/snapshot/pmd_rules_java_bestpractices.html#nonexhaustiveswitch
|
|
All methods are static. Consider adding a private no-args constructor to prevent instantiation.:
src/main/java/org/dsa/Main.java#L30
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/snapshot/pmd_rules_java_design.html#useutilityclass
|
Artifacts
Produced during runtime
| Name | Size | Digest | |
|---|---|---|---|
|
PMD Report
Expired
|
3.79 KB |
sha256:27d175c7e8a1680aa5a4d2586e215345cd07b0aeb2185061eb8c17b077f7680a
|
|