Basic linter rules

Linting is automated static analysis that enforces code quality rules without running the code. ESLint for JavaScript/TypeScript, Pylint or Ruff for Python, golangci-lint for Go, Checkstyle for Java, RuboCop for Ruby - every major language ecosystem has one or more linting tools. These tools check for a range of issues: syntax errors, undefined variables, unused imports, potential null pointer dereferences, inconsistent formatting, overly complex functions, security anti-patterns, and violations of style conventions.

At L2 (Guided), the team has moved past individual developer choice on linting. A shared linter configuration is committed to the repository, every developer uses the same rules, and - critically - CI fails if linting fails. A PR that introduces lint errors cannot be merged until the errors are resolved. This is the key difference between L1 (where linting might exist on some developers' machines, informally) and L2: the rules are enforced by the build system, not by reviewer diligence.

Basic linter rules cover the obvious things: code formatting (indentation, line length, spacing), naming conventions, unused variables and imports, unreachable code, obvious potential errors (comparing with == instead of === in JavaScript, for example). The configuration is shared across the team but is deliberately not over-engineered - it catches the things everyone agrees on, without creating friction from overly opinionated rules.

This simplicity is intentional. At L2, the goal is getting the team to agree on and enforce a baseline. The more sophisticated use cases - custom lint rules that enforce architectural decisions - are the domain of L3 (Lint-as-architecture).

Linting is among the highest-ROI investments in software quality because it catches a predictable class of issues automatically, before any human sees the code:

• Eliminates the lowest-value review comments - "Use const instead of let here," "this import is unused," "missing semicolon" - these are review comments that waste reviewer attention. Linting handles them automatically, freeing reviewers for substantive feedback.
• Enforces consistency without conflict - Style debates ("tabs vs spaces," "80 vs 120 column limit") are resolved once in the linter configuration, not relitigated in every PR review. The linter is the authority.
• Catches errors before tests - Some lint rules catch real bugs (undefined variables, unreachable code, potential type errors). Finding these during lint is faster and cheaper than finding them during testing or production.
• Makes onboarding easier - New team members don't need to memorize style conventions - the linter tells them when they've violated one. The configuration file serves as machine-readable documentation of team standards.
• Foundation for advanced automation - L3's lint-as-architecture, L4's auto-merge policies, and L5's continuous auto-refactoring all depend on a trustworthy linting infrastructure. You can't build on top of inconsistent quality gates.

The key cultural shift at L2 is accepting that a machine will block your PR. Some developers initially resist having a bot tell them their code is wrong. The right framing is: "The linter is our agreed-upon standards, running automatically. It's what we would have told you in review anyway, just faster."

1. Choose your linter - For JavaScript/TypeScript: ESLint (with Prettier for formatting). For Python: Ruff (fast, modern, covers most Pylint and Flake8 rules). For Go: golangci-lint. For Java: Checkstyle or SpotBugs. Pick the de facto standard for your ecosystem.
2. Start from a shared community configuration - eslint:recommended, pylint --rcfile=google-style, golangci-lint defaults. Extend from there rather than building from scratch. This avoids hundreds of bikeshedding decisions about which rules to include.
3. Commit the configuration to the repository - .eslintrc.json, pyproject.toml, .golangci.yml - whatever format your linter uses, commit it to the root of the repository. Every developer and CI uses the same file. No "works on my machine" linting.
4. Add a CI check that fails on lint errors - In GitHub Actions, GitLab CI, or your CI system of choice, add a lint step that runs before tests. A failing lint check blocks the PR from merging. This is the step that makes linting real - without CI enforcement, it's just advisory.
5. Fix existing violations in a dedicated PR - Before enforcing the linter on all PRs, fix the existing violations in one focused cleanup PR. Running eslint --fix or ruff --fix handles most automatically. This ensures the baseline is green before enforcement begins.
6. Install the IDE plugin for every developer - ESLint, Pylint, and golangci-lint all have IDE plugins that show violations inline as you type. Catching lint errors before a push is faster than catching them in CI. Make IDE plugin installation a team onboarding step.

Introducing too many rules at once. A linter configuration with 200 opinionated rules will generate hundreds of existing violations and substantial team pushback. Start with the minimum: errors (not warnings), the rules that every team member agrees matter. Add rules incrementally as the team builds tolerance for enforcement.

Using warnings instead of errors for important rules. Lint warnings that don't block CI are ignored. If a rule matters enough to have, make it an error that fails CI. If it doesn't matter enough to fail CI, consider removing it to reduce noise.

Inconsistent formatter and linter setup. ESLint (or Pylint) handles rule enforcement; Prettier (or Black) handles formatting. These tools need to be configured to not conflict. A common source of friction is running eslint --fix and having it conflict with Prettier's output. Use eslint-config-prettier to turn off ESLint formatting rules that conflict with Prettier.

Not auto-fixing in CI. Many lint violations can be automatically fixed by the linter itself. Consider adding a CI step that runs eslint --fix and commits the result if there are only auto-fixable violations. This reduces developer friction significantly for minor style issues.