Tabs vs Spaces: The Actual Arguments (Not the Meme)

The short answer

Use whatever your linter enforces. For Python, use spaces (PEP 8). For Go, use tabs (gofmt). For JavaScript/TypeScript, most style guides and formatters use 2 spaces. The real answer is: stop arguing and run a formatter.

The actual technical arguments

Concern	Tabs	Spaces
Accessibility	Better — blind devs using screen readers can configure tab width; fixed-width spaces can't adapt	Worse for adaptive display
File size	Slightly smaller (1 byte vs 2/4/8 spaces per indent)	Slightly larger
Per-developer preference	Each dev sets their own width in editor	Same width for everyone
Alignment of continuation lines	Painful (tabs + spaces mixed looks broken)	Clean
Display consistency (diffs, code review, rendered sites)	Varies by viewer	Identical everywhere
Editor support	Universal (but defaults differ)	Universal

What each language ecosystem actually does

• Python — PEP 8 mandates 4 spaces. Mixing tabs and spaces is a syntax error since Python 3.
• Go — gofmt uses tabs (displayed as 8 wide in most editors). No argument; it's enforced by the toolchain.
• JavaScript/TypeScript — Prettier default is 2 spaces. Airbnb, Google, Standard all use 2 spaces. Some older codebases use 4 spaces.
• Rust — rustfmt uses 4 spaces.
• Ruby — 2 spaces (community consensus, enforced by RuboCop).
• Java — 4 spaces (Sun/Oracle convention, most tools).
• HTML/CSS — 2 spaces conventional (matching nested JS inside).
• Makefiles — tabs only. Required by the language. No alternative.
• YAML — spaces only. Tabs are a parse error in most implementations.

The accessibility argument, expanded

This is the strongest argument FOR tabs and it rarely gets heard. A blind developer using a screen reader may want wide indentation (so it reads clearly); a sighted developer on a narrow laptop may want 2 spaces of indent to fit more code. Tabs let every developer configure their own view of the same file. Spaces force one width on everyone. For this reason some advocates (notably the Rust accessibility working group) push for tabs-for-indent / spaces-for-alignment as the accessible default. Most codebases still use spaces because tooling is more consistent.

Mixing tabs and spaces: don't

A file with inconsistent indentation breaks in Python, renders differently in every editor, and produces noisy git diffs. Run a formatter (Prettier, Black, gofmt, rustfmt) and commit the result. Settle the argument once at the repo level (.editorconfig, .prettierrc) and let CI enforce it.

Detecting and fixing indentation

For inspecting what a file actually contains, the diff checker reveals whitespace differences your editor might hide. The code beautifier re-indents messy code uniformly. For HTML/CSS/JS specifically, our minifiers (HTML, JS) round-trip cleanly — strip all whitespace, then re-beautify.

The meme-free conclusion

The "war" is a distraction. Real engineering time goes into things that matter: architecture, testing, perf. Pick one, automate enforcement, move on. If your team genuinely disagrees, tabs have the accessibility edge; if consistency across tools matters more than configurability, spaces win. Either is fine. Neither is worth arguing about in code review.