Tags: web-dev concept

Formatting

Date: 2026-08-17

---

Automatic, deterministic code layout. The tool’s actual purpose is to end an argument — its output being occasionally worse than a human’s is the price of nobody ever discussing it again, and that’s a good trade.

---

A formatter rewrites code to a canonical layout: indentation, line breaks, quotes, trailing commas, spacing. Prettier is the standard for web languages.

The point is the absence of debate

TIME SPENT ON FORMATTING

WITHOUT     review comments about spacing
            style debates in standups
            inconsistent files
            merge conflicts from
              reformatting
            a wiki page nobody follows

WITH        zero

Prettier is deliberately unconfigurable, and this is the design rather than a limitation. Every option is a decision a team could argue about, so the options were removed. The output is sometimes not what you’d have written, and it’s always the same.

Accepting that is the whole value proposition.

What it removes from review

BEFORE                    AFTER
"add a space here"        (formatted)
"this line is too long"   (formatted)
"use single quotes"       (formatted)
"trailing comma?"         (formatted)
                          ↓
                          review discusses
                          correctness

Formatting comments crowd out substantive ones, and they make review feel adversarial for no benefit — Code Review.

The settings that are worth setting

The few that genuinely matter:

{
  "printWidth": 80,
  "singleQuote": true,
  "semi": false,
  "trailingComma": "all"
}

trailingComma: "all" is the one with a real argument behind it — adding a line to a list produces a one-line diff rather than two, which makes every diff and every merge cleaner.

Everything else is preference. Pick, commit, stop discussing.

Formatting and linting are different jobs

	Formatter	Linter
Question	How should this look?	Is this a problem?
Fixable	Always, automatically	Sometimes
Debatable	No — that’s the point	Yes, per rule

Disable every stylistic rule in the linter. eslint-config-prettier does it in one line, and without it the two tools fight — Linting.

Where to run it

ON SAVE        in the editor
               ← the only place people
                 actually experience it

PRE-COMMIT     on changed files
               — Pre-Commit Hooks

CI             --check, fails the build

See: Pre-Commit Hooks

On-save is what makes it invisible. If formatting only happens at commit, people write unformatted code all day and see a large diff at the end.

prettier --check .     # CI: fail if unformatted
prettier --write .     # fix

The one-off reformat

Adopting a formatter on an existing codebase produces one enormous commit, which has a real cost:

git blame  →  every line attributed to
              the reformat commit

Git can be told to ignore it:

# .git-blame-ignore-revs
a3f9c2e1d4b5...   # prettier: initial format

git config blame.ignoreRevsFile .git-blame-ignore-revs

Do the reformat as its own commit, containing nothing else, and add it to that file. Otherwise you lose the history of every line in the codebase — Commit Hygiene.

Where it doesn’t apply

• Generated files — add them to .prettierignore
• Deliberately-aligned data, where the layout carries meaning. Rare, and a // prettier-ignore comment handles it
• Markdown with intentional line breaks, where reflowing changes the rendering
• Languages with their own conventional formatter — gofmt, rustfmt, black. Use those

The honest limitation

Prettier will occasionally produce something ugly — a long chained expression broken awkwardly, a JSX block that reads worse than the hand-formatted version.

That’s the trade, and it’s worth taking. The alternative isn’t consistently better formatting; it’s inconsistent formatting plus a recurring argument. The occasional awkward block is a much smaller cost than either.