Skip to content

finished mostly

finished mostly #80

Triggered via push October 9, 2024 15:55
Status Failure
Total duration 1m 23s
Artifacts 1

build.yml

on: push
Fit to window
Zoom out
Zoom in

Annotations

4 errors and 10 warnings
This class has only private constructors and may be final: src/main/java/frc/robot/extras/Alert.java#L101
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.6.0/pmd_rules_java_design.html#classwithonlyprivateconstructorsshouldbefinal
Check Format Java
Process completed with exit code 1.
Compile Java
Process completed with exit code 1.
Test Java
Process completed with exit code 1.
Do not use non-final non-private static fields: src/main/java/frc/robot/Constants.java#L321
Non-private static fields should be made constants (or immutable references) by declaring them final. Non-private non-final static fields break encapsulation and can lead to hard to find bugs, since these fields can be modified from anywhere within the program. Callers can trivially access and modify non-private non-final static fields. Neither accesses nor modifications can be guarded against, and newly set values cannot be validated. If you are using this rule, then you don't need this rule {% rule java/errorprone/AssignmentToNonFinalStatic %}. MutableStaticState (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.6.0/pmd_rules_java_design.html#mutablestaticstate
Do not use non-final non-private static fields: src/main/java/frc/robot/Constants.java#L344
Non-private static fields should be made constants (or immutable references) by declaring them final. Non-private non-final static fields break encapsulation and can lead to hard to find bugs, since these fields can be modified from anywhere within the program. Callers can trivially access and modify non-private non-final static fields. Neither accesses nor modifications can be guarded against, and newly set values cannot be validated. If you are using this rule, then you don't need this rule {% rule java/errorprone/AssignmentToNonFinalStatic %}. MutableStaticState (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.6.0/pmd_rules_java_design.html#mutablestaticstate
Do not use non-final non-private static fields: src/main/java/frc/robot/Constants.java#L388
Non-private static fields should be made constants (or immutable references) by declaring them final. Non-private non-final static fields break encapsulation and can lead to hard to find bugs, since these fields can be modified from anywhere within the program. Callers can trivially access and modify non-private non-final static fields. Neither accesses nor modifications can be guarded against, and newly set values cannot be validated. If you are using this rule, then you don't need this rule {% rule java/errorprone/AssignmentToNonFinalStatic %}. MutableStaticState (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.6.0/pmd_rules_java_design.html#mutablestaticstate
Do not use non-final non-private static fields: src/main/java/frc/robot/Constants.java#L394
Non-private static fields should be made constants (or immutable references) by declaring them final. Non-private non-final static fields break encapsulation and can lead to hard to find bugs, since these fields can be modified from anywhere within the program. Callers can trivially access and modify non-private non-final static fields. Neither accesses nor modifications can be guarded against, and newly set values cannot be validated. If you are using this rule, then you don't need this rule {% rule java/errorprone/AssignmentToNonFinalStatic %}. MutableStaticState (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.6.0/pmd_rules_java_design.html#mutablestaticstate
Do not use non-final non-private static fields: src/main/java/frc/robot/Constants.java#L399
Non-private static fields should be made constants (or immutable references) by declaring them final. Non-private non-final static fields break encapsulation and can lead to hard to find bugs, since these fields can be modified from anywhere within the program. Callers can trivially access and modify non-private non-final static fields. Neither accesses nor modifications can be guarded against, and newly set values cannot be validated. If you are using this rule, then you don't need this rule {% rule java/errorprone/AssignmentToNonFinalStatic %}. MutableStaticState (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.6.0/pmd_rules_java_design.html#mutablestaticstate
Do not use non-final non-private static fields: src/main/java/frc/robot/Constants.java#L405
Non-private static fields should be made constants (or immutable references) by declaring them final. Non-private non-final static fields break encapsulation and can lead to hard to find bugs, since these fields can be modified from anywhere within the program. Callers can trivially access and modify non-private non-final static fields. Neither accesses nor modifications can be guarded against, and newly set values cannot be validated. If you are using this rule, then you don't need this rule {% rule java/errorprone/AssignmentToNonFinalStatic %}. MutableStaticState (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.6.0/pmd_rules_java_design.html#mutablestaticstate
Do not use non-final non-private static fields: src/main/java/frc/robot/Constants.java#L445
Non-private static fields should be made constants (or immutable references) by declaring them final. Non-private non-final static fields break encapsulation and can lead to hard to find bugs, since these fields can be modified from anywhere within the program. Callers can trivially access and modify non-private non-final static fields. Neither accesses nor modifications can be guarded against, and newly set values cannot be validated. If you are using this rule, then you don't need this rule {% rule java/errorprone/AssignmentToNonFinalStatic %}. MutableStaticState (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.6.0/pmd_rules_java_design.html#mutablestaticstate
Do not use non-final non-private static fields: src/main/java/frc/robot/Constants.java#L451
Non-private static fields should be made constants (or immutable references) by declaring them final. Non-private non-final static fields break encapsulation and can lead to hard to find bugs, since these fields can be modified from anywhere within the program. Callers can trivially access and modify non-private non-final static fields. Neither accesses nor modifications can be guarded against, and newly set values cannot be validated. If you are using this rule, then you don't need this rule {% rule java/errorprone/AssignmentToNonFinalStatic %}. MutableStaticState (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.6.0/pmd_rules_java_design.html#mutablestaticstate
Avoid unused private fields such as 'red'.: src/main/java/frc/robot/Constants.java#L544
Detects when a private field is declared and/or assigned a value, but not used. Since PMD 6.50.0 private fields are ignored, if the fields are annotated with any annotation or the enclosing class has any annotation. Annotations often enable a framework (such as dependency injection, mocking or e.g. Lombok) which use the fields by reflection or other means. This usage can't be detected by static code analysis. Previously these frameworks where explicitly allowed by listing their annotations in the property "ignoredAnnotations", but that turned out to be prone of false positive for any not explicitly considered framework. UnusedPrivateField (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.6.0/pmd_rules_java_bestpractices.html#unusedprivatefield
Use one line for each declaration, it enhances code readability.: src/main/java/frc/robot/Constants.java#L544
Java allows the use of several variables declaration of the same type on one line. However, it can lead to quite messy code. This rule looks for several declarations on the same line. OneDeclarationPerLine (Priority: 4, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.6.0/pmd_rules_java_bestpractices.html#onedeclarationperline

Artifacts

Produced during runtime
Name Size
PMD Report Expired
14.5 KB