@critiq/rules 0.3.0 → 0.4.0

package/rules/java/java.correctness.lost-increment-in-assignment.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.lost-increment-in-assignment
+  title: Increment/decrement lost during assignment to same variable
+  summary: Assigning a post-incremented variable to itself (e.g., x = x++) discards the increment because the old value is assigned back.
+  rationale: In x = x++, the post-increment returns the original value, which is then written over the incremented value, making the increment a no-op.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0396
+  tags:
+    - correctness
+    - java
+    - defensive-programming
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.lost-increment-in-assignment
+    bind: issue
+emit:
+  finding:
+    category: correctness.defensive-programming
+    severity: high
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: Increment lost in `${captures.issue.text}`
+    summary: "`${captures.issue.text}` discards the increment because post-increment returns the old value and assigns it back to the same variable."
+  remediation:
+    summary: Either use `x++` alone, or assign from a different expression (e.g., `y = x++` or `x = x + 1`).

package/rules/java/java.correctness.math-max-min-swapped.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.math-max-min-swapped
+  title: Incorrect combination of Math.max and Math.min
+  summary: "Using `Math.max(A, Math.min(A, ...))` or `Math.min(A, Math.max(A, ...))` with a repeated argument is suspicious."
+  rationale: Nested Math.max/Math.min calls with a repeated first argument often indicate swapped arguments. The inner call's result is passed as the second arg, making the outer call pointless or incorrect.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0080
+  tags:
+    - correctness
+    - java
+    - logic
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.math-max-min-swapped
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: medium
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Possible swapped Math.max/Math.min arguments
+    summary: "`${captures.issue.text}` has the same variable as the outer call's first argument and the inner call's first argument, suggesting the arguments may be swapped."
+  remediation:
+    summary: "Review the nested Math.max/Math.min call and swap inner arguments if needed."

package/rules/java/java.correctness.missing-enum-switch-elements.rule.yaml

@@ -0,0 +1,43 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.missing-enum-switch-elements
+  title: Missing enum elements in switch cases
+  summary: Switch statements on enum types without a default label must cover all enum members.
+  rationale: If new enum members are added later and the switch is not updated, the code silently skips the new case — almost always a bug.
+  aliases:
+    - JAVA-E1082
+  tags:
+    - correctness
+    - java
+    - logic
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.missing-enum-switch-elements
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.82
+    tags:
+      - correctness
+      - java
+  message:
+    title: Switch on enum missing elements
+    summary: "Switch on enum type missing the following members: ${captures.issue.text}"
+  remediation:
+    summary: Add case labels for every enum member that is not covered, or add a default label to handle unknown values.

package/rules/java/java.correctness.modulus-multiplication-precedence.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.modulus-multiplication-precedence
+  title: The `%` operator has higher precedence than `*` — ambiguous expression
+  summary: Mixing `%` and `*` without parentheses creates ambiguous precedence that may not match developer intent.
+  rationale: In Java, `%` and `*` have the same precedence and are left-associative. `a % b * c` is parsed as `(a % b) * c` which may not be what the developer intended.
+  aliases:
+    - JAVA-E1080
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.modulus-multiplication-precedence
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.86
+    tags:
+      - correctness
+      - java
+  message:
+    title: Ambiguous modulus/multiplication precedence in `${captures.issue.text}`
+    summary: "Mixing `%` and `*` without parentheses can lead to misreading the expression."
+  remediation:
+    summary: Add parentheses to clarify precedence — either `(a % b) * c` or `a % (b * c)` depending on intent.

package/rules/java/java.correctness.mutable-data-exposed.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.mutable-data-exposed
+  title: Defensively copy mutable objects passed to constructors
+  summary: Assigning a mutable object (collection or array) directly to a field without a defensive copy exposes internal state.
+  rationale: When a constructor parameter references a mutable object and stores it directly, the caller can modify the field's state externally. This breaks encapsulation and can lead to unexpected behavior or security issues.
+  aliases:
+    - JAVA-E1086
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.mutable-data-exposed
+    bind: issue
+emit:
+  finding:
+    category: correctness.encapsulation
+    severity: high
+    confidence: 0.70
+    tags:
+      - correctness
+      - java
+  message:
+    title: Mutable data exposed in `${captures.issue.text}`
+    summary: "A mutable object passed to a constructor is assigned directly to a field without a defensive copy, exposing internal state."
+  remediation:
+    summary: Create a defensive copy of the mutable parameter (e.g., `new ArrayList<>(input)`, `input.clone()`) before assigning to the field.

package/rules/java/java.correctness.mutable-enum-fields.rule.yaml

@@ -0,0 +1,44 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.mutable-enum-fields
+  title: Enum fields should be final
+  summary: Enum fields that are not declared final create mutable state in a shared singleton instance.
+  rationale: "Enum constants are singletons by definition. Non-final fields make their state mutable across callers, leading to unpredictable behavior in multi-threaded environments. Declare fields as `final` and initialize them in the constructor."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E1069
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.mutable-enum-fields
+    bind: issue
+emit:
+  finding:
+    category: correctness.immutability
+    severity: medium
+    confidence: 0.82
+    tags:
+      - correctness
+      - java
+  message:
+    title: Enum field is not declared final
+    summary: "`${captures.issue.text}` in an enum body is not declared final. Enum constants are singletons; mutable fields break instance control guarantees."
+  remediation:
+    summary: Add the `final` modifier to the field and initialize it in a constructor.

package/rules/java/java.correctness.nan-comparison.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.nan-comparison
+  title: Double/Float comparison with NaN always returns false
+  summary: Comparing a floating-point value to Double.NaN or Float.NaN using == or != always yields false (or true for !=) because NaN is not equal to any value, including itself.
+  rationale: Per the IEEE 754 standard and Java Language Specification (§4.2.3, §15.21.1), NaN is unordered — it is not equal to, less than, or greater than any value, including itself. Use Double.isNaN() or Float.isNaN() instead of equality checks.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1031
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.nan-comparison
+    bind: issue
+emit:
+  finding:
+    category: correctness.types
+    severity: high
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: Comparison with NaN using == or !=
+    summary: NaN is never equal to any value, including itself. A `==` or `!=` comparison with `Double.NaN` or `Float.NaN` will not behave as expected.
+  remediation:
+    summary: Use `Double.isNaN(x)` or `Float.isNaN(x)` instead of `x == Double.NaN` or similar equality checks against NaN.

package/rules/java/java.correctness.ncopies-argument-order.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.ncopies-argument-order
+  title: "Avoid reversed arguments to `Collections.nCopies()`"
+  summary: "Passing a string as the first argument to `Collections.nCopies()` likely has the arguments reversed."
+  rationale: "`Collections.nCopies(int n, T o)` takes the count as the first argument and the object to copy as the second. Passing `nCopies(\"str\", count)` is a compile-time error when types don't match, but `nCopies(stringVar, count)` can compile with unexpected results if types align."
+  aliases:
+    - JAVA-E1090
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.ncopies-argument-order
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-misuse
+    severity: critical
+    confidence: 0.88
+    tags:
+      - correctness
+      - java
+  message:
+    title: "Possible reversed arguments to `Collections.nCopies()` in `${captures.issue.text}`"
+    summary: "`Collections.nCopies()` expects the count as the first argument and the object to copy as the second. A string literal as the first argument indicates the arguments are likely reversed."
+  remediation:
+    summary: "Swap the arguments so the count comes first: `Collections.nCopies(count, object)`."

package/rules/java/java.correctness.noallocation-method-creates-object.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.noallocation-method-creates-object
+  title: '@NoAllocation method performs object allocation'
+  summary: A method annotated @NoAllocation creates heap objects via `new`.
+  rationale: "The @NoAllocation annotation promises zero heap allocation. Creating objects with `new` inside the method body violates that contract and may cause performance regressions or library contract violations."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E1059
+  tags:
+    - correctness
+    - java
+    - allocation
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.noallocation-method-creates-object
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-usage
+    severity: medium
+    confidence: 0.78
+    tags:
+      - correctness
+      - java
+  message:
+    title: '@NoAllocation method allocates objects'
+    summary: "`${captures.issue.text}` creates a new object inside a @NoAllocation-annotated method."
+  remediation:
+    summary: Remove the allocation or remove the @NoAllocation annotation if allocation is intentional.

package/rules/java/java.correctness.non-final-immutable-fields.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.non-final-immutable-fields
+  title: Fields of immutable classes should be final
+  summary: Fields in a class annotated with @Immutable or @Value should be declared final.
+  rationale: An immutable class must guarantee that its state cannot change after construction. Non-final fields violate this contract even if the class is declared as immutable.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0055
+  tags:
+    - correctness
+    - java
+    - immutability
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.non-final-immutable-fields
+    bind: issue
+emit:
+  finding:
+    category: correctness.immutability
+    severity: medium
+    confidence: 0.80
+    tags:
+      - correctness
+      - java
+  message:
+    title: Non-final field in immutable class
+    summary: "Field `${captures.issue.text}` in an @Immutable or @Value class should be declared final."
+  remediation:
+    summary: "Add the `final` modifier to the field declaration."

package/rules/java/java.correctness.non-null-method-returns-null.rule.yaml

@@ -0,0 +1,43 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.non-null-method-returns-null
+  title: Methods annotated as non-nullable should not return null values
+  summary: Methods annotated @Nonnull, @NotNull, or @NonNull that contain explicit return null statements are buggy.
+  rationale: Returning null from a non-null annotated method defeats the purpose of the annotation and will cause NullPointerException at call sites.
+  aliases:
+    - JAVA-E1095
+  tags:
+    - correctness
+    - java
+    - null-safety
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.non-null-method-returns-null
+    bind: issue
+emit:
+  finding:
+    category: correctness.null-safety
+    severity: critical
+    confidence: 0.92
+    tags:
+      - correctness
+      - java
+  message:
+    title: Non-null method returns null
+    summary: "The method is annotated as non-nullable but contains a return null statement."
+  remediation:
+    summary: Remove the return null statement or change the method annotation to @Nullable if null is a valid return value.

package/rules/java/java.correctness.non-terminating-loop.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.non-terminating-loop
+  title: Non-terminating loop
+  summary: A loop with an unconditionally true condition has no break or return statement, causing it to run indefinitely.
+  rationale: A while(true) or for(;;) loop without a break, return, or System.exit() inside its body will never terminate, leading to program hang. This is typically a bug unless the loop is intentionally infinite (e.g., server event loops).
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1046
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.non-terminating-loop
+    bind: issue
+emit:
+  finding:
+    category: correctness.control-flow
+    severity: critical
+    confidence: 0.9
+    tags:
+      - correctness
+      - java
+  message:
+    title: Non-terminating loop
+    summary: "`${captures.issue.text}` has no exit condition, break, or return, so it runs indefinitely."
+  remediation:
+    summary: Add a break, return, or a bounded condition to the loop to allow termination.

package/rules/java/java.correctness.oddness-check-fails-negative.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.oddness-check-fails-negative
+  title: Oddness check using x % 2 == 1 will not work for negative numbers
+  summary: Using `x % 2 == 1` to check parity fails for negative values because Java's modulo preserves sign.
+  rationale: In Java, -3 % 2 == -1, so the comparison == 1 fails for negative odd numbers. Use x % 2 != 0 instead.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0405
+  tags:
+    - correctness
+    - java
+    - arithmetic
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.oddness-check-fails-negative
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: Oddness check fails for negative numbers
+    summary: Using `x % 2 == 1` to test oddness does not work for negative numbers because the modulo result preserves the sign of the dividend.
+  remediation:
+    summary: Replace `x % 2 == 1` with `x % 2 != 0` to correctly detect odd numbers including negative values.

package/rules/java/java.correctness.optional-get-without-present-check.rule.yaml

@@ -0,0 +1,44 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.optional-get-without-present-check
+  title: Optional values must be checked before being accessed
+  summary: Calling Optional.get() without a preceding isPresent() check will throw NoSuchElementException when the Optional is empty.
+  rationale: Optional.get() throws if no value is present. Always guard with isPresent() or use orElse(), orElseThrow(), or orElseGet() to safely handle empty Optionals.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E1013
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.optional-get-without-present-check
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-usage
+    severity: high
+    confidence: 0.55
+    tags:
+      - correctness
+      - java
+  message:
+    title: Optional.get() called without presence check
+    summary: "`${captures.issue.text}` calls Optional.get() without a detectable isPresent() guard. This will throw NoSuchElementException if the Optional is empty."
+  remediation:
+    summary: Guard with isPresent() before calling get(), or use orElse(), orElseThrow(), or orElseGet() instead.

package/rules/java/java.correctness.optional-null.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.optional-null
+  title: Optional variable or return value set to null
+  summary: An Optional-typed variable is assigned null or a method returns null for an Optional return type.
+  rationale: Optional is designed to represent absence without null. Assigning null to an Optional defeats its purpose and risks NullPointerException.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1022
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.optional-null
+    bind: issue
+emit:
+  finding:
+    category: correctness.nullability
+    severity: critical
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Optional variable or return value assigned null
+    summary: An Optional-typed variable or method return is set to null instead of using Optional.empty() or Optional.ofNullable().
+  remediation:
+    summary: Use Optional.empty() to represent absence, or Optional.ofNullable(value) for nullable values.