A linter inspects source code for potential or realized faults without running it. It catches code smells such as deprecated-method calls, undeclared variables, unused variables, debugging statements, and violations of language or team conventions before review. section 5.3.2 section 4.4.4
Linters scan code through rules, with each rule usually checking one concern. Teams choose the rules’ granularity and severity, then run linting during development or as a precheck so reviewers can focus on higher-stakes questions. section 5.3.2 section 5.3
Use linting as one part of a broader quality workflow:
- Pair it with formatting, static analysis, and automated testing; these mechanisms overlap but address different automated checks. section 5.3
- Keep obvious issues out of pull requests by running linting before submission and during development. section 4.4.4 section 5.3.2
- Monitor repeated escapes from the linter; recurring problems may justify a new rule or an adjusted precheck. section 4.4.4
- Prefer dedicated formatters for formatting enforcement because linting tools may be slower and less consistent at that job. section 5.3.2
A small rule with a visible payoff
A JavaScript team used ESLint rules including no-console, no-var, eqeqeq, and no-unneeded-ternary. The last rule favors the direct check `let thingToCheck = input === 3;` over the unnecessarily complicated `let thingToCheck = input === 3 ? true : false;`. During an ES6 migration, the team initially classified rules as warnings. section 5.3.2
Listing 5.7 ESLint Rules used by Adrienne’s team
"rules": {
no-var: "error", #1
no-duplicate-imports: "error", #2
no-await-in-loop: "error", #3
eqeqeq: "error", #4
no-alert: "error", #5
no-console: "error", #6
no-unneeded-ternary: "error" #7
}
Browse the complete ESLint rule set used by the team, including severity-marked checks for variables, imports, loops, equality, alerts, console calls, and ternaries. section 5.3.2
