code-style-lint

Code Style & Lint Enforcement

Style is not a matter for human debate. A language's established, widely-adopted formatter is the single source of truth for how code looks, enforced automatically before a human ever reads the diff, so no reviewer ever spends attention on brace placement or import order again.

Phase 1: Adopt the ecosystem's standard, don't invent one

Reach for the tool the language community has already converged on, rather than a project-specific configuration built from scratch:

Language	Formatter	Linter
Go	gofmt (or goimports): not configurable by design	go vet, staticcheck
Rust	rustfmt	clippy
Python	black (or ruff format)	ruff / flake8, type-checked with mypy/pyright
JavaScript / TypeScript	prettier	eslint
Java	google-java-format	Error Prone, Checkstyle

Where no single de facto tool dominates, fall back to a named, published style guide (e.g. the Google style guides) rather than an ad hoc house style; a house style is a style nobody outside the project can look up, onboard against, or get tooling support for.

Phase 2: Prefer opinionated over configurable

An opinionated formatter (gofmt, prettier, black) that offers few or no style options is worth more than a configurable one, even though it feels less flexible; every open configuration option is a decision the team has to make once and then defend forever, which reopens exactly the debate the formatter exists to close. Where the chosen tool does expose options, set them once at project setup, commit the config file, and treat re-opening that discussion as a smell: a request to change a formatter setting midway through a project is usually a style preference relitigating itself, not a real defect being fixed.

Phase 3: Enforcement layers, in order

1. Editor / local, on save or on commit. The formatter runs automatically before code is even staged; a pre-commit hook (or editor format-on-save) so a contributor never has to remember to run it manually.
2. CI, in blocking mode. Re-run the same formatter and linter in CI and fail the build on any diff or violation. This is the actual gate; local hooks can be skipped or misconfigured, so CI is what a merge actually depends on, not a courtesy check.
3. Code review never re-litigates style. If a review comment is about formatting, spacing, or naming convention the linter could catch, that is a signal the pipeline is missing a check, not a legitimate review comment; fix Phase 1/2's tooling, don't leave the enforcement to a human's attention in every future review.