@critiq/rules 0.2.0 → 0.4.0

package/rules/go/go.correctness.hidden-goroutine.rule.yaml

@@ -0,0 +1,55 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.hidden-goroutine
+  title: Function body wraps entirety in hidden goroutine
+  summary: >-
+    A function whose entire body consists of a single `go func()` call
+    obscures the concurrent nature of the operation and makes error
+    handling and cancellation invisible to the caller.
+  rationale: >-
+    Wrapping an entire function body in a goroutine (`go func() { ... }()`)
+    hides the fact that the function runs concurrently. This makes it
+    impossible for the caller to await completion, handle errors, or
+    cancel the operation. Prefer explicit goroutine invocation at the
+    call site with proper error propagation via channels or errgroups.
+  aliases:
+    - GO-E1007
+  tags:
+    - correctness
+    - go
+    - concurrency
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.hidden-goroutine
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.55
+    tags:
+      - correctness
+      - go
+      - concurrency
+  message:
+    title: Function body is entirely wrapped in an anonymous goroutine
+    summary: "`${captures.issue.text}` wraps its entire body in `go func()` — concurrency is hidden from callers"
+  remediation:
+    summary: >-
+      Remove the enclosing goroutine and let the caller decide whether to
+      invoke the function concurrently. Use `errgroup.Group` or channels
+      for error propagation and cancellation.

package/rules/go/go.correctness.http-nobody-nil.rule.yaml

@@ -0,0 +1,52 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.http-nobody-nil
+  title: http.NoBody instead of nil
+  summary: Use http.NoBody for HTTP requests with no body instead of nil.
+  rationale: >-
+    When creating an HTTP request with `http.NewRequest` or
+    `http.NewRequestWithContext` where no body is needed, pass `http.NoBody`
+    instead of `nil`. `http.NoBody` is an explicit sentinel that indicates
+    no body is intended, while `nil` can be ambiguous.
+  aliases:
+    - GO-R4001
+  tags:
+    - correctness
+    - go
+    - api-usage
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.http-nobody-nil
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-usage
+    severity: medium
+    confidence: 0.9
+    tags:
+      - correctness
+      - go
+      - api-usage
+  message:
+    title: Use `http.NoBody` instead of `nil` in `${captures.issue.text}`
+    summary: >-
+      An HTTP request is created with a `nil` body. Use `http.NoBody` instead
+      to explicitly signal no body is intended.
+  remediation:
+    summary: >-
+      Replace `nil` with `http.NoBody` as the body argument.
+      For example, `http.NewRequest("GET", url, http.NoBody)`.

package/rules/go/go.correctness.identical-binary-operands.rule.yaml

@@ -0,0 +1,48 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.identical-binary-operands
+  title: Binary operation with identical operands
+  summary: Identical expressions on both sides of an operator is likely a copy-paste error.
+  rationale: >-
+    Using the same expression on both sides of a binary operator (e.g., x == x,
+    a < b || a < b) does not change the outcome and indicates a bug or
+    tautology.
+  aliases:
+    - CRT-D0008
+  tags:
+    - correctness
+    - go
+    - bug-risk
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.identical-binary-operands
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.8
+    tags:
+      - correctness
+      - go
+      - bug-risk
+  message:
+    title: Binary operation with identical operands in `${captures.issue.text}`
+    summary: "Both sides of the operator are the same expression. This is likely a copy-paste bug."
+  remediation:
+    summary: >-
+      Replace one side with the intended expression or extract to a variable.

package/rules/go/go.correctness.impossible-interface-nil-check.rule.yaml

@@ -0,0 +1,56 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.impossible-interface-nil-check
+  title: "Impossible interface nil check"
+  summary: >-
+    Interface value compared to nil when the underlying concrete type is always
+    non-nil. The nil check is always false because an interface holding a nil
+    concrete pointer is not itself nil.
+  rationale: >-
+    In Go, an interface value is nil only when both the type and value are nil.
+    A function returning `*MyError` (concrete pointer) assigned to an `error`
+    interface variable produces a non-nil interface even when the concrete
+    pointer is nil. The subsequent `if err != nil` check is always true,
+    masking potential bugs. For more detail, see the Go FAQ on nil error values.
+  aliases:
+    - GO-W1001
+  tags:
+    - correctness
+    - go
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.impossible-interface-nil-check
+    bind: issue
+emit:
+  finding:
+    category: correctness.semantics
+    severity: high
+    confidence: 0.35
+    tags:
+      - correctness
+      - go
+      - experimental
+  message:
+    title: Interface nil check is always true
+    summary: >-
+      ${captures.issue.text} assigns a concrete pointer type to an error
+      interface — the nil check will never fire.
+  remediation:
+    summary: >-
+      Return `error` directly from the function instead of a concrete pointer
+      type, or check nil on the concrete value before assigning to the
+      interface. See the Go FAQ on nil error values for more details.

package/rules/go/go.correctness.incomplete-nil-check.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.incomplete-nil-check
+  title: Incomplete nil check on slice
+  summary: Checking `xs != nil` before indexing a slice is not sufficient — a non-nil empty slice still panics on index access.
+  rationale: >-
+    In Go, a nil slice has no elements, but an empty (non-nil) slice also has no
+    elements. Checking `xs != nil && xs[0] == ...` panics on an empty non-nil
+    slice. Use `len(xs) > 0` to guard against both nil and empty slices.
+  aliases:
+    - CRT-D0017
+  tags:
+    - correctness
+    - go
+    - bug-risk
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.incomplete-nil-check
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.8
+    tags:
+      - correctness
+      - go
+      - bug-risk
+  message:
+    title: Incomplete nil check on slice
+    summary: "Nil check on slice before index access — use `len(xs) > 0` instead to guard against empty non-nil slices"
+  remediation:
+    summary: >-
+      Replace `xs != nil && xs[index]` with `len(xs) > 0 && xs[index]` to
+      correctly handle both nil and empty slices.

package/rules/go/go.correctness.integer-truncation.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.integer-truncation
+  title: Potentially lossy integer truncation in comparison
+  summary: Narrowing an integer type before comparison may lose precision.
+  rationale: >-
+    When a wider integer type is narrowed (e.g., `int16(x)` where `x` is int32)
+    and then compared, the narrowing truncates the value before the comparison.
+    This can lead to incorrect results if the wider type holds values outside
+    the narrower type's range. Prefer widening the smaller type instead.
+  aliases:
+    - CRT-D0020
+  tags:
+    - correctness
+    - go
+    - bug-risk
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.integer-truncation
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.65
+    tags:
+      - correctness
+      - go
+      - bug-risk
+  message:
+    title: Lossy integer truncation in comparison
+    summary: "Comparing a value after narrowing conversion may lose precision — widen the smaller type instead"
+  remediation:
+    summary: >-
+      Instead of narrowing the wider type, widen the smaller type before
+      comparison. For example, replace `int16(x) < y` with `x < int32(y)`
+      where `x` is int32 and `y` is int16.

package/rules/go/go.correctness.interface-any-preferred.rule.yaml

@@ -0,0 +1,50 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.interface-any-preferred
+  title: Use `any` instead of `interface{}`
+  summary: Go 1.18 introduced `any` as an alias for `interface{}`. Prefer `any` for brevity.
+  rationale: >-
+    Since Go 1.18, `any` is a built-in alias for `interface{}`. Using `any`
+    is shorter and clearer. The `interface{}` syntax is older and more verbose.
+  aliases:
+    - GO-R3001
+  tags:
+    - correctness
+    - go
+    - clarity
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.interface-any-preferred
+    bind: issue
+emit:
+  finding:
+    category: correctness.style
+    severity: high
+    confidence: 0.85
+    tags:
+      - correctness
+      - go
+      - clarity
+  message:
+    title: Use `any` instead of `interface{}` in `${captures.issue.text}`
+    summary: >-
+      The `interface{}` type can be replaced with `any` (available since Go 1.18)
+      for shorter and clearer code.
+  remediation:
+    summary: >-
+      Replace `interface{}` with `any`. For example, `map[string]interface{}`
+      becomes `map[string]any`.

package/rules/go/go.correctness.nil-error-returned.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.nil-error-returned
+  title: Returning nil value with nil error
+  summary: Returning nil, nil may indicate a missing result or an error that should be returned instead.
+  rationale: >-
+    Returning nil for both the value and the error in a function that returns
+    (any, error) is often a mistake. The caller may expect a non-nil value on
+    success, or an error should be returned to indicate why the value is nil.
+  aliases:
+    - CRT-D0013
+  tags:
+    - correctness
+    - go
+    - bug-risk
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.nil-error-returned
+    bind: issue
+emit:
+  finding:
+    category: correctness.exceptions
+    severity: high
+    confidence: 0.65
+    tags:
+      - correctness
+      - go
+      - bug-risk
+  message:
+    title: Returning nil value with nil error
+    summary: "Returning nil, nil in a function that returns (value, error) is suspicious. Provide a meaningful value or return an error."
+  remediation:
+    summary: >-
+      Return a meaningful value alongside nil, or return a non-nil error to
+      explain why the value is nil.

package/rules/go/go.correctness.off-by-one-index.rule.yaml

@@ -0,0 +1,48 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.off-by-one-index
+  title: Off-by-one index access
+  summary: Indexing an array or slice at len(arr) reads one past the last valid element.
+  rationale: >-
+    Accessing `arr[len(arr)]` panics at runtime because valid indices range from
+    0 to len(arr)-1. The correct access is `arr[len(arr)-1]` for the last element.
+  aliases:
+    - CRT-D0015
+  tags:
+    - correctness
+    - go
+    - bug-risk
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.off-by-one-index
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.85
+    tags:
+      - correctness
+      - go
+      - bug-risk
+  message:
+    title: Index at `len(arr)` is off-by-one
+    summary: "Indexing array/slice at `len(arr)` is off-by-one — last valid index is `len(arr)-1`"
+  remediation:
+    summary: >-
+      Use `arr[len(arr)-1]` to access the last element, or ensure the index is
+      strictly less than `len(arr)`.

package/rules/go/go.correctness.redundant-type-declaration.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.redundant-type-declaration
+  title: Redundant type in variable declaration
+  summary: The explicit type in `var count int = 10` is unnecessary — Go can infer it from the RHS literal.
+  rationale: >-
+    When a variable is declared with `var name Type = literal`, Go's type inference
+    can determine the type from the literal value. The explicit type annotation is
+    redundant and adds noise. Prefer `var name = literal` for clarity.
+  aliases:
+    - GO-C5001
+  tags:
+    - correctness
+    - go
+    - simplification
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.redundant-type-declaration
+    bind: issue
+emit:
+  finding:
+    category: correctness.style
+    severity: high
+    confidence: 0.8
+    tags:
+      - correctness
+      - go
+      - simplification
+  message:
+    title: Redundant type declaration in `${captures.issue.text}`
+    summary: >-
+      The type annotation is redundant because Go can infer it from the literal
+      value on the right-hand side.
+  remediation:
+    summary: >-
+      Remove the explicit type. Write `var name = value` instead of
+      `var name Type = value`.

package/rules/go/go.correctness.signedness-casting.rule.yaml

@@ -0,0 +1,56 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.signedness-casting
+  title: Integer signedness lost through narrowing cast
+  summary: >-
+    Narrowing an integer type (e.g., `int8(x)`, `uint16(y)`) can lose
+    precision or produce unexpected results when the source value exceeds
+    the target type's range.
+  rationale: >-
+    Converting between integer types of different widths truncates the value.
+    For example, `int8(int16(200))` produces `-56` due to overflow. When
+    the result of `strconv.Atoi` or another integer expression is cast to a
+    narrower type, validate the value fits before converting, or widen the
+    target type instead.
+  aliases:
+    - GO-E1006
+  tags:
+    - correctness
+    - go
+    - bug-risk
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.signedness-casting
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.55
+    tags:
+      - correctness
+      - go
+      - bug-risk
+  message:
+    title: Narrowing integer cast may lose signedness
+    summary: "`${captures.issue.text}` narrows an integer value — the result may overflow or lose precision"
+  remediation:
+    summary: >-
+      Validate the source value fits within the target type's range before
+      casting, or widen the target type instead. For `strconv.Atoi` results,
+      check the value against `math.MinInt8` / `math.MaxInt8` etc. before
+      narrowing.

package/rules/go/go.correctness.string-concat-simplify.rule.yaml

@@ -0,0 +1,52 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.string-concat-simplify
+  title: String concatenation can be simplified
+  summary: String concatenation patterns like `strings.Join(parts, "")` or `fmt.Sprintf("%s%s", a, b)` can be simplified.
+  rationale: >-
+    Using `strings.Join` with an empty separator is equivalent to direct string
+    concatenation but is less readable. Similarly, `fmt.Sprintf` with only `%s`
+    placeholders can be replaced with `strings.Join` or direct concatenation
+    for clarity and performance.
+  aliases:
+    - GO-R4003
+  tags:
+    - correctness
+    - go
+    - simplification
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.string-concat-simplify
+    bind: issue
+emit:
+  finding:
+    category: correctness.simplification
+    severity: medium
+    confidence: 0.75
+    tags:
+      - correctness
+      - go
+      - simplification
+  message:
+    title: String concatenation can be simplified in `${captures.issue.text}`
+    summary: >-
+      This string concatenation pattern can be simplified. Use direct
+      concatenation or `strings.Join` for clarity.
+  remediation:
+    summary: >-
+      Replace `strings.Join(parts, "")` with direct concatenation, or
+      replace `fmt.Sprintf("%s%s...", a, b)` with `a + b`.

package/rules/go/go.correctness.suspicious-regex-pattern.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: go.correctness.suspicious-regex-pattern
+  title: Suspicious unescaped dot in regex pattern
+  summary: An unescaped dot (`.`) in a regex pattern matches any character, not a literal dot.
+  rationale: >-
+    When using `regexp.Compile` or `regexp.MustCompile`, an unescaped dot in the
+    pattern matches any character (wildcard). For matching literal dots (e.g., in
+    domain names like `google.com`), the dot must be escaped as `\.`.
+  aliases:
+    - CRT-D0019
+  tags:
+    - correctness
+    - go
+    - bug-risk
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - go
+  paths:
+    include:
+      - "**/*.go"
+    exclude:
+      - "**/*_test.go"
+      - "**/testdata/**"
+      - "**/vendor/**"
+match:
+  fact:
+    kind: go.correctness.suspicious-regex-pattern
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.75
+    tags:
+      - correctness
+      - go
+      - bug-risk
+  message:
+    title: Unescaped dot in regex pattern
+    summary: "Unescaped dot (`.`) in regex matches any character — escape it as `\\.` for a literal dot"
+  remediation:
+    summary: >-
+      Escape literal dots in regex patterns by replacing `.` with `\\.`. For
+      example, `google.com` should be `google\\.com`.