code-linting

Topics in the source

• Code linting
• 1. Find out what already exists
• 2. Pick the stack's tooling
• 3. Separate formatting from linting
• 4. Choose rules by what they prevent
• 5. Adopt without a thousand-file diff
• 6. Wire it where it actually runs
• When the lint job is already failing

A linter's job is to make an entire category of review comment impossible. Every rule you enable should retire a conversation nobody should have again. The failure mode: a lint config so noisy that people run it with --no-verify, or so lax it catches nothing. Both end with the linter ignored. Aim for a config where every reported problem is worth fixing, because that is what keeps the signal trusted. Never add a second linter alongside a working one. Check for config files, CI lint steps, and editor settings before proposing anything. Also check whether it currently passes. A config that has been failing for months is a different problem from a missing config — that one is a decision to make, not a tool to install. Done when: you know which tools are configured, whether they run in CI, and whether they currently pass. Read the matching reference for the recommended tool, its config, and the rules worth enabling or disabling: | Stack | Reference | | --- | --- | | Python | references/python.md | | JavaScript / TypeScript | references/javascript.md | | Go | references/go.md | | Rust | references/rust.md | | Java / Kotlin | references/jvm.md | | Ruby | references/ruby.md | | Shell | re

This is an excerpt. Refer to the complete source and its current requirements.