Linters and formatters: why argue about spaces

Two different tools

They get confused constantly.

A formatter brings code to a uniform appearance: indentation, line breaks, quotes, spacing. It doesn't think about meaning, only looks. It runs automatically on save.

A linter looks for problems: unused variables, unreachable code, suspicious comparisons, misspelled names, potential bugs. It rewrites nothing without asking; it reports.

You want both, and neither replaces the other.

Why bother working alone

A formatter saves attention. You stop thinking about where to break a line, which frees your head for the actual problem.

A linter catches real bugs. A typo in a variable name, a comparison that's always true, a forgotten variable — all found before you run anything.

The change history becomes readable. Without consistent formatting, every edited file appears wholly changed because the editor reshuffled the quotes. Working out what actually changed becomes impossible.

Why bother in a team

So you don't argue. Discussing indentation in review comments is the most pointless waste of time there is.

The rule is simple: agree once, automate it, never discuss it again. Anything a robot can check shouldn't occupy a person.

Setting it up

For Python. One modern tool both lints and formats, and it's fast:

pip install ruff
ruff check .
ruff format .

For JavaScript and TypeScript. Usually a linter plus a formatter, configured through a file in the project.

The key step: enable format-on-save in your editor. Otherwise you'll forget and it won't help.

And add the check to your automated build — then unformatted code simply won't pass.

Not hurting yourself

Don't enable every rule at once. Strict rule sets contain hundreds of checks, half of which don't apply to your situation. Start with the recommended set.

Disable what obstructs you deliberately. If a rule fights your style and you understand why, switch it off in the configuration rather than silencing it in every file.

Don't reformat the whole project inside a work commit. A project-wide reformat goes in its own commit so it doesn't mix with meaningful changes.

What to settle first

• Line length. Agree and forget.
• Quotes. Single or double doesn't matter; consistency does.
• Indentation. Two spaces, four, tabs — any choice, as long as it's one.
• Semicolons where the language permits both.

What it gives you at interview

Tidy, consistent code reads more easily, and that's visible at a glance. Configured tooling in the repository also shows someone who worked with more in mind than "make it run".

It's a cheap improvement: half an hour of setup and all your projects look neater.