A well-configured linter is the first level of automated code review. It frees human reviewers from style discussions so they can focus on architecture and logic.
The debate over spaces versus tabs, semicolons in JavaScript, brace placement in Java — these discussions consume precious code review time and generate unnecessary friction. Linters and code formatters settle these questions once and for all, automatically. Code is either compliant or it doesn't compile. No more debates.
ESLint is the de facto standard for JavaScript and TypeScript. It combines style checking and potential error detection: unused variables, missing dependencies in React hooks, unresolved imports. Prettier is its natural complement for pure formatting: it automatically reformats code on save, without possible discussion. On the Java side, Checkstyle verifies naming and structure conventions, PMD detects problematic patterns, and SpotBugs (successor to FindBugs) analyzes bytecode to detect potential bugs.
The key to success is integration into the developer workflow. A linter that only runs in CI discourages: errors surface too late. It must run on save (via the editor), on commit (via a pre-commit hook with Husky) and in CI as a final safety net. A linter that is configured but ignored has no value — it is the adoption of the whole team that creates value, not the tool itself.
- ESLint + Prettier for JS/TS, Checkstyle + SpotBugs for Java
- Integrate linting on save in your IDE
- Add a pre-commit hook via Husky to block violations
- Use CI as the last safety net