Setting up a linter is easy. Getting it sustainably adopted by an entire team is as much a cultural challenge as a technical one. Here's how to create conventions that stick.
The biggest mistake when setting up a team linter is configuring it unilaterally and then imposing it. Developers who
did not participate in the decision will experience it as an external constraint — and will find ways around it
(eslint-disable, Checkstyle exceptions). The configuration must be a team agreement, not an individual decision.
Organize a collective working session to define the core rules. Start with a recognized preset — Airbnb or Standard for JavaScript, Google Style Guide for Java — and adjust together what doesn't suit your context. Each disabled rule must have a justification documented in the configuration comments. This traceability prevents future regressions and helps newcomers understand the choices.
Governance is key over time. Designate a configuration owner (can rotate), establish a process to propose changes (dedicated PR, team discussion), and hold a quarterly review. When new rules are added retroactively to a large codebase, use the autofix function to automatically correct existing violations in a dedicated PR — avoid mixing style fixes with functional changes.
- Build the configuration as a team, not alone
- Start from a known preset, adjust at the margins
- Document every exception in the config
- Create a clear process for evolving the rules