An experienced engineer joins a team whose committed formatting standard conflicts with their own strong preferences. How should this be handled, and what principle governs whose style wins?
answer
- Codebase should look like one author wrote it
- Team standard > personal preference, always
- Change the config through process, not by defection
- Arbitrary (braces/quotes) vs substantive (EOL, encoding, version pin)
- Make compliance unavoidable, not documented
basics
~20 sThe team standard wins. Code should look like one person wrote it, so personal preference gives way to the committed convention; if you disagree, propose a change to the standard rather than formatting your own files differently.
solid answer
~60 sThe governing principle is that **a codebase should read as though written by a single person**, because a reader who must re-tune to each author's habits pays a tax on every file. So the committed team standard wins over individual preference, always, and the standard is expressed as configuration a tool enforces — not as a document people are expected to remember. The healthy handling: adopt the standard immediately and without visible resentment (a senior person visibly resisting is far more damaging than any indentation choice); if the objection is substantive, raise it as a proposal against the standard itself, with a concrete argument and a plan for the repo-wide reformat and blame-ignore entry it would require. Distinguish *arbitrary* conventions (brace placement, quote style) where the correct answer is 'whatever is already there', from conventions with actual downstream cost (mixed line endings breaking scripts, no final newline, tabs inside significant-whitespace files) where a real argument exists. The worst outcome is per-author formatting: it maximizes diff noise and makes blame useless.
go deeper
Say the team standard wins and you should just configure your editor to match; raise disagreements as a suggestion rather than formatting your own files differently.
Add the reason — code should read as if one person wrote it — and that the standard lives in committed config the formatter enforces, not in a document.
Describe the legitimate change process (argue from shared cost, show the reformat + blame-ignore migration cost, accept the outcome) and name per-author formatting as the worst outcome.
Separate arbitrary conventions from substantive ones (line endings, encoding, final newline, formatter version pinning), and treat visible senior defection as a leadership failure that licenses exceptions and reopens a solved coordination problem.
### The principle *Clean Code* states it plainly: a team of developers should agree to a single formatting style, and every member should use it, so that **the software has a consistent style — it looks like one person wrote it, not a team of warring individuals.** Everything else in this topic follows from that. The reason is cognitive. A reader opening an unfamiliar file spends a small amount of effort orienting to its conventions before absorbing content. If conventions vary per author, that cost is paid on every file, forever, by everyone — a large aggregate expense to buy each individual author a small amount of comfort. The trade is obviously bad, which is why it is not really a debate among experienced people; it just needs to be said out loud. ### Why this is a leadership question, not a style question When a senior or principal engineer visibly resists the local standard, several bad things happen beyond the formatting itself: - **It licenses exceptions.** If the most experienced person opts out, the standard is now advisory, and juniors learn that conventions apply selectively by seniority. - **It converts a solved coordination problem back into an open one.** The value of a convention is that nobody thinks about it; reopening it costs far more than any conceivable improvement to it. - **It signals misplaced priorities** — spending political capital on brace placement rather than on architecture, testing, or delivery. So the expected behavior is: adopt it on day one, silently and completely; run the formatter; do not hand-format against it. ### The legitimate path to change Standards should not be immutable — they should be *changeable through a defined process rather than through unilateral defection*: 1. **Make the case in terms of shared cost, not taste.** 'I prefer 4 spaces' is not an argument. 'Our 120-column limit means our diffs don't fit our review tool's side-by-side pane' is. 2. **Show the migration cost honestly.** Any change means a repo-wide reformat, a new `.git-blame-ignore-revs` entry, and conflicts on every open branch. Sometimes that cost alone settles the question. 3. **Change the configuration, not the document.** The standard's real representation is `.editorconfig` plus the formatter config in the repo. A style guide that isn't machine-enforced is a wish. 4. **Accept the outcome.** If the proposal loses, it is closed. Repeatedly relitigating is the same defection in slower form. ### Distinguishing arbitrary from substantive conventions A principal-level answer separates two categories rather than treating all formatting as equally arbitrary: **Arbitrary (consistency is the entire value):** brace on same line vs. next line, single vs. double quotes, 2 vs. 4 spaces, trailing commas, import ordering scheme. Correct answer: match what exists; never argue. **Substantive (real downstream cost):** - **Line endings** — mixed CRLF/LF breaks shell scripts, produces whole-file diffs across platforms, and confuses hashing/caching. Fix with `.gitattributes` (`text=auto`, `eol=lf`) plus `.editorconfig`, not with per-developer local config alone. - **Final newline** — its absence makes line-oriented command-line tools misbehave and produces spurious 'no newline at end of file' diff markers. - **Trailing whitespace** — invisible churn in diffs; trivially auto-stripped. - **Encoding** — non-UTF-8 files break tooling and reviews. - **Tabs in whitespace-significant languages** — genuinely error-prone when mixed with spaces. - **Formatter version drift** — an unpinned formatter means CI and laptops disagree; this looks like a style dispute and is actually a reproducibility bug. Being able to say 'these six things are worth an argument, the rest are not' is the mark of someone who has been through this several times. ### Onboarding implications The standard should be *unavoidable* rather than *documented*: committed editor settings, format-on-save, a pre-commit hook installed by the repo's setup script, and a CI check. A new joiner should hit the correct format automatically on their first save, never having read a style document. If someone can only comply by remembering rules, the setup is incomplete. ### The failure mode to name explicitly Per-author formatting — different files, or different regions of files, formatted to different tastes — is strictly worse than any single choice. It maximizes reformat churn in diffs, makes blame attribute lines to whoever last reformatted them, generates merge conflicts on untouched logic, and makes reviewers read past noise. When asked this question, naming that outcome as the thing being avoided is what separates a principle-based answer from a deferential one.
- Are there formatting conventions genuinely worth arguing about, rather than just matching what exists?Yes, a small set with real downstream cost: line endings (mixed CRLF/LF breaks scripts and produces whole-file diffs — fix via `.gitattributes`), missing final newlines, trailing whitespace, non-UTF-8 encoding, tabs mixed into whitespace-significant languages, and an unpinned formatter version (a reproducibility bug disguised as a style dispute). Brace placement, quote style, and indent width are not in that set.
- How should the standard be represented so a new joiner complies without effort?As enforced configuration rather than prose: `.editorconfig`, formatter config committed to the repo, committed editor settings with format-on-save, a pre-commit hook installed by the repo setup script, and a CI check. If compliance requires remembering rules from a document, the setup is incomplete.
- What if the existing codebase has no standard at all?Then there is nothing to defer to, and the right move is to establish one: pick the most opinionated formatter for the ecosystem (fewest options to argue about), adopt its defaults rather than designing a bespoke style, land one pure reformat commit, add it to `.git-blame-ignore-revs`, and turn on the CI check. Choosing defaults over a custom style pre-empts the entire debate.
Like a newspaper's house style guide: individual reporters may prefer different comma rules, but the paper reads as one voice because everyone uses the house sheet — and changes go through the editor, not through each writer quietly ignoring it.