A linter is a static analysis tool that reads source code without executing it and reports likely bugs, suspicious constructs and violations of style rules. Well-known examples include ESLint for JavaScript, Pylint and Ruff for Python, and RuboCop for Ruby.
Why it matters
Linters catch problems early, in the editor or in continuous integration, before they reach review or production. They find unused variables, unreachable code, missing awaits, unsafe comparisons and inconsistent naming. They also enforce team conventions automatically, so code reviews can focus on design rather than nitpicks. Rules are configurable, and teams usually start from a recommended preset and adjust it.
Example
// .eslintrc excerpt: "eqeqeq": "error", "no-unused-vars": "warn"
function check(x) {
const unused = 1; // warning: 'unused' is assigned but never used
if (x == null) {} // error: use === instead of ==
}Running eslint . prints each finding with a file, line and rule name, and many rules can be fixed with --fix.
Common mistakes
- Disabling rules wholesale with comments instead of fixing the cause.
- Treating warnings as noise until hundreds pile up.
- Overlapping a linter's formatting rules with a separate formatter, causing conflicts.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.