What Is a Linter? Linter vs Static Analysis vs Formatter (2026)

Direct answer

A linter reads source code without executing it and flags likely bugs, risky constructs and style violations by matching rules against the code’s syntax tree. It is the fastest and cheapest of four distinct analysis layers: formatter (layout), linter (per-file rules), static analyser (cross-file dataflow and taint), AI reviewer (intent and judgement). Each catches what the layer below structurally cannot. Serious AI reviewers bundle linters rather than replacing them. Verified 2026-10-19.

What is a linter?

Direct answer: A linter parses your source into an abstract syntax tree and matches rules against that tree, reporting likely bugs and suspicious constructs without running the code. It is fast because it never executes anything, and bounded because it can only find what its rules describe. ESLint, Ruff, RuboCop, golangci-lint and Clippy are the per-language standards. Verified 2026-10-19.

The name is a piece of computing history. In 1978 Stephen Johnson at Bell Labs wrote a utility called lint that scanned C programs for bugs the compiler let slide - the “lint” being the fuzz you pick off a sweater. The idea stuck, and today every major language has one or several.

Because a linter never runs the program, it is safe to run on every keystroke, which is why it lives in your editor. And because it reasons about the shape of code rather than its behaviour, it is bounded by its rule set. A linter is pattern-matching over the structure of your code: fast, cheap, deterministic, and blind to anything nobody wrote a rule for.

That last property is the whole reason the other three layers exist.

What are the four layers of automated code analysis?

Direct answer: Formatter, linter, static analyser, AI reviewer. Scope increases and determinism decreases at every step. A formatter rewrites layout. A linter matches per-file rules. A static analyser traces dataflow across files. An AI reviewer reads intent. Skip one and you leave a predictable, nameable gap rather than a vague loss of quality. Verified 2026-10-19.

This framing is the single most useful thing on this page, because almost every tool-selection argument on an engineering team is actually an argument about which layer should own a concern.

Layer	What it analyzes	Scope	Deterministic?	Typical latency	Example tools
1. Formatter	Token layout only	Single file	Yes, fully	Milliseconds	Prettier, Black, gofmt, rustfmt
2. Linter	Syntax tree, rule matches	Usually single file	Yes	Milliseconds to seconds	ESLint, Ruff, Pylint, RuboCop, Clippy
3. Static analyser (SAST)	Control flow and dataflow graphs	Cross-file, whole program	Yes	Seconds to many minutes	SonarQube, Semgrep, CodeQL, Snyk Code
4. AI reviewer	The diff plus retrieved context	Cross-file, plus intent from the PR description	No	1 to 10 minutes per PR	CodeRabbit, Greptile, Qodo, Anthropic Code Review

And here is the part that actually decides tooling arguments - what each layer cannot do:

Layer	Catches	Structurally cannot catch
Formatter	Inconsistent indentation, line length, quote style, trailing commas	Anything about meaning. It will happily format a bug beautifully
Linter	Unused imports, if (x = 1), missing await, shadowed variables, unreachable code, mutable default arguments	Cross-file dataflow, taint reaching a sink two files away, whether a design is right, whether a test asserts anything
Static analyser	SQL injection via taint from request to query, path traversal, insecure deserialization, cross-file null propagation	Intent. Whether a missing authorization check is a bug or a deliberate public endpoint. Business-logic errors
AI reviewer	Missing auth checks, misleading names, tests that assert nothing, violated repo conventions, logic that contradicts the PR description	Deterministic reproducibility, an auditable “same ruleset ran on every commit” guarantee, and anything outside the context it retrieved

Notice the asymmetry. Layers 1 to 3 fail by omission - they do not find things. Layer 4 fails by variance - it finds different things on different runs, and some of them are wrong. That is not a reason to skip it. It is a reason not to make it a blocking merge gate on its own, and a reason the deterministic layers must stay in place underneath.

Why the layering is not theoretical

The two vendors who have been most explicit about architecture both build exactly this stack:

• CodeRabbit pairs an LLM with 40-plus open source linters and static analysers. The AI does not replace the deterministic layer, it sits on top of it and reasons about what the deterministic layer reported plus the diff. CodeRabbit publishes a full language-to-linter map covering 50-plus tools, including Squawk for Postgres migrations, Verilator, and zizmor for GitHub Actions workflows (verified 2026-10-18).
• DeepSource runs 5,000-plus deterministic rules across 30-plus languages before its AI agent engages (verified 2026-10-18). Same architecture, different ratio.

The gap worth knowing about: CodeRabbit’s published linter map has no Python type checker - no mypy, no pyright - and no Error Prone or SpotBugs for Java (verified 2026-10-18). If your Python codebase treats type annotations as a correctness mechanism, or your Java team leans on Error Prone’s bug patterns, those checks are not arriving from CodeRabbit and you must keep running them in CI yourself. That is the sort of detail that only matters once, at the moment you decide what to switch off.

Also worth noting for contrast: Greptile’s language claim is “all languages supported”, which is unfalsifiable, and Qodo, Gitar, Cursor Bugbot, Anthropic and GitHub Copilot publish no language list at all (verified 2026-10-18). CodeRabbit publishing a map with visible gaps is more useful than a competitor publishing nothing.

What is the difference between a linter and a formatter?

Direct answer: A formatter changes layout only and is deliberately unconfigurable so style arguments end by fiat. A linter changes nothing by default, reports likely bugs and risky patterns, and often requires human judgement to fix. If a rule is about where a brace goes, it belongs to the formatter. If it is about whether the code is right, it belongs to the linter. Verified 2026-10-19.

A formatter has no opinion about correctness. It makes code look consistent and ends every style argument because there is nothing left to configure. The deliberate lack of options is the feature, not a limitation - Prettier and gofmt both made that a design principle.

A linter has opinions about meaning. It will tell you a variable is never used, a promise is never awaited, or you compared with is where you meant ==. Many linter rules can auto-fix. Some only warn, because the correct fix depends on what you meant.

The practical rule: no style rule should live in your linter if a formatter can own it. Lint rules about line length and import order generate review comments, merge conflicts, and arguments. A formatter running on save generates none of those. Push every cosmetic rule down to layer 1 and your linter’s remaining output becomes signal.

What a linter catches - real examples

Concrete beats abstract. ESLint flagging a classic in JavaScript:

// no-cond-assign catches an assignment where a comparison was meant
if (user.role = "admin") {   // ESLint error: expected '===' not '='
  grantAccess();
}

let total = computeTotal();   // no-unused-vars: 'total' is never read
return computeTotal();

// no-floating-promises (typescript-eslint): the await is missing
async function save(user) {
  db.write(user);             // fire and forget, errors vanish
}

Ruff catching problems in Python:

import os          # F401: 'os' imported but unused
import sys

def get_config(key, cache={}):   # B006: mutable default argument
    if key is "prod":            # F632: use '==' to compare literals, not 'is'
        return load_prod()
    return cache.get(key, load_default())

None of this is a syntax error. All of it compiles or runs. That is exactly the gap linters fill: the code the compiler accepts but a human would call a bug. Rules fall into rough buckets:

• Probable bugs - unused variables, unreachable code, is instead of ==, missing await, mutable default arguments, assignment in a condition.
• Risky patterns - shadowed variables, implicit coercions, broad exception catches, any escape hatches in TypeScript.
• Style and consistency - naming conventions, import ordering, max line length. Most of this is better owned by the formatter.
• Shallow security - eval on user input, disabled certificate verification, obvious credential patterns. Deep security is layer 3’s job.

What a linter demonstrably misses

# Layer 2 sees nothing wrong here. Layer 3 traces the taint. Layer 4 asks why.

# handlers.py
def search(request):
    return run_report(request.GET["q"])      # linter: fine

# reports.py
def run_report(term):
    return db.execute("SELECT * FROM docs WHERE body LIKE '%" + term + "%'")

A per-file linter analyzing handlers.py sees a function call. Analyzing reports.py it sees string concatenation into a query with no known taint source in scope. Neither file looks wrong alone. Cross-file taint analysis is the line between “linter” and “SAST”, and it is also the single most expensive capability in static analysis - which is why it is almost always the thing behind a paywall. Semgrep’s interfile taint requires the proprietary Pro engine; Semgrep CE cannot do it at all (verified 2026-10-18). We work through this in SAST vs DAST and what is CodeQL.

Where linting fits in the workflow

A linter delivers value in proportion to how early it runs. The layered setup:

1. In the editor. The linter runs as you type and underlines problems instantly. This is where developer experience lives - you fix the issue before it is committed.
2. As a pre-commit hook, on changed files only. A hook that lints the whole repo gets disabled within a week. One that lints the staged diff in under two seconds survives. See our pre-commit hooks guide.
3. In CI as a required check. The enforcement gate. Even if someone bypasses the hook with --no-verify, CI blocks the merge. This is what makes the standard non-optional.

Running it only in CI is a common mistake - developers discover lint failures after pushing, which is slow and annoying. Running it only locally is the opposite mistake - anyone can skip the hook. Lint locally for speed and in CI for enforcement; skipping either layer costs you either developer experience or reliability.

One CI mechanic worth knowing if your lint job is a required check behind GitHub’s merge queue: the merge_group event is separate from pull_request and push. A required job triggered only on pull_request will never report on a queued merge, and GitHub’s docs are explicit that “the merge will fail as the required status check will not be reported” (verified 2026-10-18). See what is a merge queue.

How do you adopt a linter on a legacy codebase?

Direct answer: Use the ratchet. Baseline every existing violation so the build stays green, then fail only on new violations in changed files. The warning count becomes monotonically non-increasing without a cleanup sprint, and nobody is asked to stop shipping features. A cleanup sprint is the failure mode, not the solution. Verified 2026-10-19.

Turning a full rule set on in a mature repository produces thousands of findings and one predictable outcome: the team sets the job to non-blocking and forgets it. The ratchet avoids that:

1. Generate a baseline. Most linters support this directly, or you snapshot the current violation set to a committed file.
2. Gate changed files only. CI fails if a file touched by the PR introduces a new violation. Untouched files are exempt.
3. Let the campground rule do the cleanup. Violations disappear as files get edited for other reasons, which is also when the context is loaded in someone’s head.
4. Promote rules one at a time. Move a warning to an error only once the existing count for that rule is zero.

This is exactly the tactic that works for technical debt generally, and the reason it works is the same: gating new code is politically cheap, while demanding a cleanup of old code competes with the roadmap and loses.

Linters and code review

Every issue a linter catches is an issue a human does not have to comment on. When formatting and lint rules are automated, review comments stop being about spacing and start being about design and correctness. A reviewer arguing about import order is a wasted reviewer.

This matters more than it sounds, because review attention is the scarce resource. Our own dataset of 2,189 merged pull requests across 12 repositories found that the median PR spends 52.7% of its open-to-merge life waiting for the first human to look at it (harvested from the GitHub GraphQL API on 2026-10-18, published in pull request review time). If a meaningful share of what that human then says could have been said by a rule, you have wasted the most expensive step in the pipeline. The same principle drives our code review checklist: style belongs to a formatter, not a reviewer.

Beyond the linter - tools that go further

When you outgrow a single-file linter, several platforms fold linting into deeper analysis and pull results into code review.

SonarQube is the industry-standard example - thousands of rules across 35-plus languages, pairing linting with deeper bug and security detection, then gating merges through quality gates. One precision point that gets conflated constantly: SonarQube Community Build analyzes the main branch only and cannot analyze pull requests - Sonar’s own docs state Developer Edition is the minimum for branch and PR analysis. SonarQube Cloud’s free tier does include PR analysis, up to 50k lines on private projects, and never expires. Community Build also excludes C, C++, Dart, Objective-C, PL/SQL, PowerShell, R, Shell, Swift and T-SQL and excludes taint analysis, though it does include secrets detection (verified 2026-10-18). See SonarQube pricing and is SonarQube free.

Semgrep sits deliberately between a linter and a SAST engine - rules you write in a grep-like syntax that looks like the code they match, with dataflow underneath. Semgrep Free covers 10 contributors and 10 private repos; Teams is modular at Code $30, Supply Chain $30 and Secrets $15 per contributor per month (verified 2026-10-18). Rule maturity is uneven: 20 rulesets at GA, 2 beta, 19 experimental, with cross-file dataflow in only 8 languages. Semgrep pricing and Semgrep vs ESLint go deeper.

DeepSource runs 5,000-plus deterministic analyzers across 30-plus languages before its AI agent engages, with Autofix remediating many findings automatically. Two 2026 facts most comparisons miss: DeepSource was acquired by Harness on 9 September 2026, and its AI review is billed separately from the seat at $8 per 10K processed lines on Standard and $15 per 10K on Advanced, with a $100 annual AI credit per user (verified 2026-10-18). That changes the real cost of the roughly $24 seat materially. See DeepSource pricing and DeepSource vs ESLint.

Sourcery leans into refactoring - it flags smelly patterns and proposes concrete rewrites in pull requests, strongest on Python, at Pro $12/seat/mo and Team $24 billed annually (verified 2026-10-18). Codacy aggregates 40-plus languages with quality gates, free forever on its Developer tier and from $18/dev/mo yearly on Team. For language-specific picks see best code review tools for JavaScript and for Python, plus best static analysis tools buyers guide.

Which linter should I use per language?

Direct answer: ESLint or Biome for JS/TS, Ruff plus mypy or pyright for Python, RuboCop for Ruby, golangci-lint for Go, Clippy for Rust, Checkstyle plus Error Prone or SpotBugs for Java, clang-tidy for C and C++. Pair each with the language’s canonical formatter and resist configuring the formatter. Verified 2026-10-19.

Language	Linter	Formatter	Type / deeper checker	Note
JavaScript / TypeScript	ESLint, or Biome for a single fast binary	Prettier, or Biome	tsc --noEmit	Biome formats and lints, which removes one tool
Python	Ruff	Ruff format, or Black	mypy or pyright	Ruff is not a type checker. You need a second tool
Ruby	RuboCop	RuboCop autocorrect	Sorbet or Steep	RuboCop spans lint and format
Go	golangci-lint	gofmt, gofumpt	go vet is bundled in	golangci-lint is an aggregator, not one linter
Rust	Clippy	rustfmt	The compiler does the heavy lifting	Ships with the toolchain
Java	Checkstyle	google-java-format, Spotless	Error Prone or SpotBugs	Not in CodeRabbit’s published map
C / C++	clang-tidy	clang-format	Compiler sanitizers, Coverity	clang-tidy spans lint and light static analysis
SQL migrations	Squawk (Postgres)	-	-	In CodeRabbit’s map; rare elsewhere

Two places teams get caught. First, Ruff is not a type checker - adopting Ruff and deleting mypy loses real coverage. Second, a linter aggregator is not a linter - golangci-lint’s value is entirely in which sub-linters you enable, and the defaults are conservative.

Common mistakes with linters

• Treating warnings as noise. A linter with 4,000 ignored warnings is worse than no linter. Ratchet, do not sprint.
• Confusing lint with formatting. Let the formatter own layout and the linter own correctness, so they do not fight over the same lines.
• No shared config. If each developer has different rules, review devolves into style debates. Commit one config to the repo and make CI the source of truth.
• Expecting a linter to find deep bugs. A per-file linter will not catch cross-file taint. That is layer 3.
• Deleting the deterministic layer after buying an AI reviewer. The vendors themselves do not do this. CodeRabbit bundles 40-plus linters; DeepSource runs 5,000-plus rules first.
• Assuming the AI reviewer’s linter bundle covers your language fully. Check the published map. No Python type checker and no Error Prone for Java in CodeRabbit’s, as of 2026-10-18.
• Blocking merges on a non-deterministic layer alone. An LLM reviewer that returns different findings on re-run makes a poor sole gate. Keep a deterministic required check underneath it.

How we verified this

Checked on 2026-10-19: internal link targets against the live content tree in this repository, and the four-layer capability claims against the tool documentation summarised in our 2026-10-18 fact table.

Carried from the 2026-10-18 verification pass, read directly from vendor documentation and pricing pages:

• CodeRabbit pairing an LLM with 40-plus linters, its published 50-plus tool language map, and the specific gaps: no Python type checker, no Error Prone or SpotBugs for Java.
• DeepSource running 5,000-plus deterministic rules across 30-plus languages before its AI agent engages; the Harness acquisition on 9 September 2026; AI review billed at $8 per 10K lines (Standard) and $15 per 10K (Advanced) with a $100 annual AI credit per user.
• Semgrep Free limits (10 contributors, 10 private repos, 60 AI credits), Teams modular pricing, ruleset maturity counts (20 GA / 2 beta / 19 experimental), cross-file dataflow in 8 languages, and interfile taint requiring the proprietary Pro engine.
• SonarQube Community Build versus SonarQube Cloud free tier, the language exclusions, and the correction that secrets detection is available in Community Build.
• Sourcery at Pro $12 / Team $24 per seat per month annual; Codacy Developer free forever and Team from $18/dev/mo yearly.
• Greptile’s unfalsifiable “all languages supported” claim, and the absence of any published language list from Qodo, Gitar, Cursor Bugbot, Anthropic and GitHub Copilot.
• GitHub’s merge_group documentation and the required-status-check deadlock.

Our own data: the 52.7% figure for the share of a median PR’s open-to-merge life spent waiting for a first human reviewer comes from our own harvest of 2,189 human-authored merged PRs across 12 repositories via the GitHub GraphQL API on 2026-10-18, published in pull request review time. Bot authors, bot reviewers and self-reviews were excluded. Only merged PRs are in frame, which biases latency down.

What we could not verify:

• No published benchmark measures linter precision or recall per rule across tools. Vendor false-positive claims (including DeepSource’s historical sub-5% figure) are vendor-stated and unreplicated by any party without a commercial stake.
• No independent false-positive rate, precision figure or noise measurement has been published for any shipping commercial AI code reviewer (checked 2026-10-19). SWE-PRBench and CR-Bench publish false-positive data, but for bare models in fixed harnesses, not purchasable products.
• The 1978 origin of Unix lint and its attribution to Stephen Johnson is widely documented historical record, not something we verified against a primary Bell Labs source.
• Linter latency figures here are order-of-magnitude characterisations from ordinary use, not a controlled benchmark. We did not run one.

Disclosure: Gitar is a paid sponsor of aicodereview.cc, and Sonar - which owns SonarQube, referenced above - acquired Gitar in May 2026. Nothing on this page was adjusted for that.

Recommendations

Criteria: cost per finding, determinism, and whether the layer catches something no other layer can.

Every team, no exceptions: a formatter on save with zero configuration, and a linter in the editor plus CI. This is the highest return per hour of setup in all of software tooling, and it is free in every mainstream language.

Teams of 2 to 20: add Semgrep Free in CI as your layer 3 (10 contributors, 10 private repos) before you add an AI reviewer. Deterministic cross-file analysis costs nothing and never surprises you. Then add one AI reviewer on top once the deterministic layers are quiet.

Teams of 20 to 200: pay for layer 3 properly - SonarQube Cloud or Semgrep Teams - and pick an AI reviewer that is explicit about the deterministic layer underneath it. CodeRabbit and DeepSource are the two that document this architecture clearly, which is a reason to prefer them over tools that publish no language list at all. Check the linter map against your stack before you switch anything off.

On a legacy codebase: ratchet. Baseline, gate changed files only, promote rules one at a time. Do not schedule a cleanup sprint - it competes with the roadmap and loses. See AI code review on legacy codebases.

What not to do: do not delete your linters because you bought an AI reviewer. The vendors did not, and they know their own products best.

Further reading

• Static Code Analysis Tools - The Definitive Guide
• SAST vs DAST - What Is the Difference?
• What Are Code Smells?
• What Is Technical Debt?
• Best Code Quality Tools in 2026
• Code Review Checklist for Authors and Reviewers