Linter

A linter is a static analysis tool that scans source code without executing it, looking for style violations, likely bugs, and code smells — unused variables, inconsistent formatting, unreachable code, missing error handling, or violations of a team's agreed conventions. Popular linters include ESLint (JavaScript/TypeScript), Pylint and Ruff (Python), RuboCop (Ruby), and golangci-lint (Go). Why it matters for AI/SaaS builders: a linter is the cheapest, fastest layer of quality control in the whole pipeline — it runs in milliseconds locally in the editor and again in seconds in CI, catching entire classes of bugs (like using `==` instead of `===` in JavaScript, or an unhandled promise rejection) before a human reviewer ever needs to spend time on them. It also enforces a consistent style automatically, removing "tabs vs. spaces"-style debates from code review entirely. For teams leaning on AI-generated code, a strict lint config is a cheap automated backstop that catches a meaningful share of AI mistakes (unused imports, inconsistent naming, missed null checks) before a human even opens the diff. How it works: a linter parses source into an abstract syntax tree and runs a configurable set of "rules" against it, each rule pattern-matching for a specific issue and reporting a file/line/column plus a message. Many linters distinguish between "errors" (must fix, blocks CI) and "warnings" (should fix, doesn't block), and many rules are auto-fixable (the linter can rewrite the code itself, e.g. `eslint --fix`). Linters are typically wired into the editor (real-time red squiggles), a pre-commit hook (blocks a bad commit locally), and CI (blocks a bad merge). Worked example: a developer writes `const [data, setData] = useState()` followed later by `data.map(item => item.name)` without a null check. ESLint's `react-hooks` and TypeScript's strict-null-checking rules flag it immediately in the editor: "Object is possibly 'undefined'." The developer fixes it to `data?.map(...)`. Separately, they leave an unused `import { useEffect } from 'react'` in the file; ESLint's `no-unused-vars` rule flags it, and running `eslint --fix` automatically removes the dead import — no human review time spent on either issue. Multiply this across a codebase with dozens of contributors and thousands of commits, and the linter is quietly catching hundreds of small issues a month that would otherwise either slip into production or eat up a reviewer's attention on trivial matters instead of the logic that actually needs human judgment. Most teams also wire the linter into a pre-commit hook, so violations are caught and often auto-fixed locally before a commit is even made, meaning CI's linting stage — and the reviewer's time — is reserved for the rare case where something genuinely slipped through.