Day 1 of 60 · Static analysis & type-time

Linting & formatting

Most fights in code review aren't about correctness, they're about style. A linter is the cheapest way to make those fights extinct.

ProblemStyle drift, common bug patterns, and review bikeshedding.

How it works

Configurable static analyzers that check for known anti-patterns and enforce style. Auto-fix where possible. Run pre-commit and in CI.

Try it

A self-contained mini-lab. Click through to see the technique catch a real bug.

eslint review.js
Click Run ESLint to scan the file.

What it catches

Anti-patterns (loose equality, unused promises, dead code, missing await). Eliminates entire classes of style argument from review.

Tools

ESLint · OSS ruff · OSS golangci-lint · OSS clippy · OSS

Verdict by project size

Small
Must
Medium
Must
Large
Must
Extra-large
Must

Cost

Project size Setup Maint / mo Tool / mo CI / run
Small <10k LOC 2h 0.5h $0 +0.5m
Medium 10–100k LOC 1d 2h $0 +1m
Large 100k–1M LOC 3d 8h $0 +2m
Extra-large >1M LOC 8d 30h $0 +5m
Setup = engineer-days to first useful run · Maint = engineer-hours / month at steady state · Tool = out-of-pocket $ / month · CI = minutes added (or saved) per pipeline run

Lifecycle & ownership

When in lifecycle
Code Build
Pre-commit / IDE · Runs locally before code leaves the developer's machine.
Who owns it
Developer
Authoring + the inner loop
Collaborates with: Security / AppSec

Reference implementations

Quick check

What is linting *least* effective at finding?

One question. Pick the best answer. Your streak is saved locally on this device.

Save the lesson

Download SVG ↓

Screenshot for a 1:1, drop it in Slack, or download the SVG.

thinkbridge THE VALIDATION ATLAS DAY 1 OF 60 STATIC ANALYSIS & TYPE-TIME Linting &formatting Most fights in code review aren't about correctness , they're about style. A linter is the cheapest way to makethose fights extinct. FIVE-MINUTE LESSON · ONE QUICK-CHECK QUESTION There’s a new way there
All 60 days →