Code Linting

Linting is automated static checking of source for style, correctness, and common bug classes before merge. We adopt it as a Technique: pick team standards once, encode them in config, and make failures block Pull Requests so review debates opinions instead of repeating the same nits.

Blurb

In computer programming, lint or linter is any tool that flags suspicious constructs, likely programming errors, bugs, stylistic errors, and suspicious constructs.

Summary

Why adopt: stops endless formatting and “you missed a semicolon” threads; catches whole classes of defects cheaply; pairs with Shift Left and DevSecOps when security linters run on the same PR path.

Layers (typical stack):

Rules of thumb:

• Config lives in the repo (.editorconfig, eslint.config.js, .golangci.yml); version with code.
• Required checks on main: a green linter run is not optional.
• Fix or suppress with intent; do not disable rules globally because one legacy folder whines.
• Linters complement Code Review; they do not replace human judgment on design.

Not the same as: Code Scanner products (vendor SKUs), Policy as Code for Terraform/K8s (Conftest), or Unit Testing (behavior vs style/static rules).

Details

When to add Codacy: many repos and languages and leaders need a single quality scorecard; otherwise Super-Linter plus native linters is enough.