What Is Linting? Static Code Analysis Explained
Length:
4 min
Published:
June 9, 2026
What is linting?
Linting is the automatic checking of source code for errors, risky patterns, and style problems. The tool that does it is a linter, and it works through static analysis: it reads the code and reasons about it without actually running the program.
That last part is the key idea. A linter does not execute your code or test what it returns. It inspects the text the way a careful reviewer would, looking for things that are very likely to be a mistake. An unused variable, a comparison that can never be true, a function that promises to return a value but sometimes does not. The linter spots these the moment you write them, long before the code reaches a test or a user.
In plain words
A linter is a spellchecker for code. A spellchecker does not understand the meaning of your sentence, but it knows that "teh" is almost certainly a typo and that a sentence with no verb looks wrong. A linter does the same for code: it does not know what your program is supposed to do, but it recognises the patterns that usually mean trouble and underlines them while you type.
Why it matters and how to adopt it
Linting catches a whole class of problems before they cost anyone time. A typo in a variable name, a forgotten await, an unreachable branch: these are cheap to fix when the editor flags them in red, and expensive to find when they show up as a bug in production. The earlier the feedback, the cheaper the fix.
It also settles arguments that should never be arguments. Tabs or spaces, single or double quotes, where the braces go. A linter (often paired with a formatter) enforces one agreed style automatically, so reviews focus on logic instead of cosmetics. New people on the team write code that matches everyone else's from day one.
Adopting it is straightforward, and it pays off fastest when you do it in this order:
- Pick the standard tool for your language. ESLint or Biome for JavaScript and TypeScript, Ruff for Python, clippy for Rust, golangci-lint for Go.
- Start with a recommended ruleset, then adjust. Do not hand-write hundreds of rules on day one.
- Run it in your editor so developers see issues as they type, not an hour later.
- Run it in CI so nothing merges with linting errors. The editor is the helpful nudge; CI is the safety net.
Common pitfalls
- Too many rules, too soon. A wall of warnings on every save teaches people to ignore the linter. Begin with a sensible default set and add rules as the team agrees on them.
- Confusing linting with formatting. A linter finds likely bugs and bad patterns. A formatter only rearranges layout. Modern tools blur the line, but the distinction matters: turn off style rules in your linter that your formatter already handles, or the two will fight.
- Drowning warnings instead of fixing them. If a rule constantly fires false alarms, either fix the rule or switch it off explicitly. A backlog of ignored warnings hides the real ones.
- A linter is not a test. It proves nothing about whether your code does the right thing. It only rules out a category of obvious mistakes. You still need tests.
Related articles:
- What is Developer Experience and why you should care - Why small frictions in daily work add up, and what good tooling fixes.
- Context engineering: a new developer skill - Giving AI tools the right context, including the rules your linter enforces.
- What is Vibe coding? - Building software by prompting AI, where automated checks matter more than ever.
Want to stay one step ahead?
Don't miss our best insights. No spam, just practical analyses, invitations to exclusive events, and podcast summaries delivered straight to your inbox.