Linter

Structural Medium oracle Predictive

Catches structural inconsistencies that are syntactically valid but semantically suspect. Lower oracle strength than a type checker, but faster feedback on style and common traps.

A linter sits between compilation and type checking — it catches things the compiler won’t (unused variables, unreachable code, style violations) but with less authority. A linter can be wrong; a compiler cannot.

How it gets gamed

Linter authority is a budget, and it can be spent:

  • Disable, don’t fix. # noqa, // eslint-disable-line, and rule exclusions in config turn findings into noise by decree. A rising ratio of suppressions to findings is the sensor telling you it is being overridden.
  • Rule-set erosion. Teams start with a strict preset, then loosen one rule per fight until the linter agrees with everything. The linter still “passes” while detecting less.
  • Style-only drift. If every enabled rule is stylistic, the linter becomes a formatting tax with no correctness value, and people learn to ignore the whole tool — including the rules that were worth reading. The answer is not to loosen it. Formatting should not be in the linter at all: hand it to an autoformatter that rewrites the file without asking, so nobody spends attention on it, and keep the linter for rules that catch real bug classes — unreachable code, unused results, suspicious comparisons. A linter arguing about brace placement is occupying a slot a tool would have silently fixed.

The meta-signal is the suppression count. Track it like a metric, not a lint error.

What it cannot detect

A linter cannot detect behavioral correctness — it operates on syntax and patterns, not execution. It also produces false positives, which erodes its authority over time.

Categories: Structural

References

Publications

Tooling

  • ESLintPluggable JavaScript/TypeScript linter
  • ruffFast Python linter and formatter
  • golangci-lintGo linter aggregator
  • SemgrepMulti-language static analysis with custom rules