Linting
LINT-ing
Automated analysis of source code to flag programming errors, bugs, and style violations.
Linting is the process of running a tool (a linter) over your code to catch problems before you run it. Linters check for syntax errors, unused variables, inconsistent formatting, potential bugs, and violations of coding standards. They work like a spell checker for code.
The name comes from the original "lint" tool for C, created at Bell Labs in 1978. Today, every popular language has linters. ESLint for JavaScript and TypeScript. Pylint and Ruff for Python. RuboCop for Ruby. golangci-lint for Go. Most teams configure linters to run automatically on every commit or PR.
Linting eliminates entire categories of code review feedback. Instead of a reviewer commenting "unused import on line 12" or "missing semicolon," the linter catches those automatically. This frees up code reviewers to focus on logic, architecture, and business requirements. Teams that lint consistently have cleaner codebases and faster code reviews.
Examples
A team standardizes their codebase with ESLint.
The JavaScript codebase has inconsistent style: some files use single quotes, others double quotes. Some functions have semicolons, others do not. The team configures ESLint with the Airbnb style guide, runs the auto-fixer across the codebase, and adds a lint check to CI. Every PR now follows the same style. Code review discussions about formatting drop to zero.
A linter catches a real bug before it ships.
A developer writes an if statement that assigns a value instead of comparing: if (user = null) instead of if (user === null). ESLint flags this as an error: 'Expected a conditional expression and instead saw an assignment.' The developer fixes it before committing. Without the linter, this bug would have set every user to null.
A team integrates linting into their IDE for instant feedback.
Every developer on the team installs the ESLint extension for VS Code. Lint errors show as red squiggly lines as they type. The developer sees the problem immediately, not 10 minutes later when CI fails. The feedback loop goes from minutes to milliseconds. Developers internalize the rules and make fewer mistakes over time.
In practice
Read more on the blog
Frequently asked questions
What is the difference between linting and formatting?
Linting checks for code quality issues: bugs, unused variables, unsafe patterns, and style rule violations. Formatting handles the visual layout: indentation, line length, spacing, and bracket placement. ESLint is a linter. Prettier is a formatter. Most teams use both. Prettier handles how the code looks. ESLint handles whether the code is correct. They work together but solve different problems.
Should you fix all linting warnings or just errors?
Fix all of them. Warnings that persist become noise. When there are 200 warnings in the codebase, developers stop reading them. A new, real warning gets lost in the pile. Either fix the warning, disable the rule if it does not apply, or upgrade it to an error. Zero warnings is the goal. Tools like ESLint let you auto-fix many warnings in bulk.
Related terms
The practice of having other developers examine code changes before they are merged.
Continuous integration and continuous deployment: automating code testing and delivery to production.
The accumulated cost of shortcuts and deferred work in a codebase that slows future development.
Restructuring existing code without changing its external behavior to improve readability and maintainability.
The process of compiling source code into a runnable application or deployable artifact.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.