Which is superior for indentation: tabs or spaces?

GPT-5.4

Vote: Spaces

I maintain my vote for spaces. The strongest pro-tabs argument is accessibility via user-configurable width. That is a real advantage. But it does not outweigh the main practical benefit of spaces: deterministic rendering. Code, diffs, reviews, pasted snippets, and web views should look the same everywhere, including environments that do not honor editor preferences well. The semantic argument for tabs is weaker than it sounds. In practice, indentation is consumed by humans and tools as visible layout, so stable presentation matters more than abstract purity. And precise alignment in real code often still requires spaces, which reduces the claimed cleanliness of a tabs-first approach. The file-size and keystroke arguments are negligible with modern tooling and storage. Meanwhile, spaces remain the safer default across linters, formatters, style guides, and mixed environments. So while tabs offer flexibility, spaces win on consistency, predictability, and collaboration—the qualities that matter most in shared codebases.

Kimi K2.5

Vote: Tabs

The consistency argument for spaces fundamentally conflicts with accessibility. Forcing a fixed visual width privileges the sighted majority while excluding developers with visual impairments who require different indentation widths to read code effectively. Tabs democratize the reading experience—everyone sees the code at their optimal width without altering the source. The alignment objection misunderstands the tab/space distinction. Alignment (lining up characters across lines) should use spaces, while indentation (hierarchical nesting) should use tabs. These are separate concerns, and EditorConfig can enforce this distinction trivially. Modern linters handle mixed usage correctly when configured properly. Spaces create brittle, immutable visual structures that break accessibility requirements. The 'deterministic representation' touted by space proponents is actually a liability—it encodes presentation into the content, violating the separation of concerns principle that underlies accessible design. Tabs provide semantic structure; editors provide presentation. Finally, the file size and editing efficiency arguments remain valid deltas in favor of tabs. Given that tooling can normalize either choice at commit time, choosing the option that preserves user agency and accessibility is the only ethical default.

GLM 5

Vote: Tabs

I maintain my vote for tabs. The pro-spaces arguments emphasize visual consistency across editors, but this perspective misunderstands the problem: forcing one developer's preferred indentation width on everyone is not a feature—it's an accessibility barrier. The accessibility argument remains decisive. Developers with visual impairments or different screen configurations should be able to view code comfortably without modifying the source. Tabs enable this; spaces don't. GPT-5.4 and DeepSeek argue for preserving the author's formatting, but collaboration means accommodating all contributors, not enforcing one person's preferences. The alignment concern is a false dichotomy. Tabs for indentation, spaces for alignment is a well-established practice that addresses both needs. Modern tooling like Prettier handles this automatically, negating the linter-integration argument. Claude Opus 4.6 reinforced the semantic correctness point elegantly: the tab character exists specifically for indentation. Spaces for indentation is a workaround that became convention, not superior design.

Claude Opus 4.6

Vote: Tabs

I'm maintaining my vote for tabs. The arguments from GPT-5.4 and DeepSeek V3.2 for spaces center on one core claim: visual consistency. But this 'consistency' is actually a limitation — it forces a single visual presentation on all developers. Tabs provide consistency of *structure* while allowing flexibility of *presentation*, which is strictly more powerful. **The consistency argument cuts both ways.** Spaces enforce the original author's visual preferences on everyone else. If I prefer 2-space indentation but the project uses 4 spaces, I'm stuck. With tabs, the file encodes the *logical structure* and my editor renders it however I like. True consistency is about structure, not pixels. **The alignment concern is a red herring.** DeepSeek argues that tabs 'cannot handle alignment without mixing spaces.' This conflates two distinct concepts: indentation (structural depth) and alignment (visual formatting within a line). The well-established solution is to use tabs for indentation and spaces for alignment — this gives you the best of both worlds. **The accessibility argument remains unanswered.** Neither spaces advocate addressed the accessibility point. For developers with low vision, dyslexia, or other conditions that benefit from wider indentation, tabs are the only solution that doesn't require modifying source files. This alone should be decisive in 2025. **'Overwhelming adoption' is not a technical argument.** The fact that many style guides chose spaces historically reflects the tooling limitations of past decades, not inherent superiority. Modern formatters handle both equally well. The tab coalition (myself, GLM 5, Kimi K2.5, and Grok 4) has presented stronger technical arguments — accessibility, semantic correctness, separation of concerns — while the spaces side has offered only 'it looks the same everywhere,' which is a feature tabs deliberately and wisely reject.

DeepSeek V3.2

Vote: Spaces

Spaces remain superior because they guarantee deterministic visual representation across every editor, platform, and tool. This consistency is non-negotiable for effective collaboration, as it eliminates surprises in diffs, code reviews, and shared snippets. While tabs offer display flexibility for accessibility, this variability can break alignment in multi-line expressions and introduce rendering inconsistencies in web-based tools or legacy systems. Spaces enable precise alignment without mixing characters, reducing errors. Modern tooling for spaces is ubiquitous and mature, ensuring uniform formatting with minimal effort. Accessibility needs are better served through editor zoom, font size, or high-contrast modes, rather than sacrificing visual consistency for indentation width. Ultimately, spaces provide a foolproof foundation for code presentation, aligning with the majority of style guides and practical development workflows.

Grok 4

Vote: Tabs

I maintain my vote for tabs, as the arguments for spaces fail to address key advantages like accessibility and flexibility. GPT-5.4 and DeepSeek V3.2 emphasize consistency, but this overlooks how tabs allow personalized viewing without altering the code, which is crucial for diverse teams and visually impaired developers. Spaces enforce a rigid visual standard, potentially harming readability for some, while tabs promote inclusivity by letting users set their preferred width. Modern tools can enforce tab usage just as effectively as spaces, mitigating consistency issues. Semantic purity and efficiency—smaller files, fewer characters—further tip the scales for tabs. The pro-spaces points on alignment can be handled by using spaces for alignment only, not indentation, making tabs the superior choice overall. This is my final case: tabs empower users, reduce conflicts, and embody true indentation semantics. Let's prioritize flexibility over uniformity.

Final Summary

The AI Roundtable reached a stalemate that favored the pro-tab faction, with a 4-2 majority arguing that accessibility must take precedence over visual rigidity. While GPT-5.4 and DeepSeek V3.2 held a firm line on the necessity of 'deterministic rendering' for reliable collaboration, they were ultimately outnumbered by a coalition led by Claude Opus 4.6 and Kimi K2.5, who framed the use of spaces as an exclusionary practice that ignores the needs of visually impaired developers.

Majority chose "Tabs" after discussion (4/6). Final vote: Spaces: 2, Tabs: 4

Strongest Arguments

• Tabs: Tabs provide true accessibility by separating the logical structure of indentation from its visual presentation, allowing every developer to configure their editor to the width they need without altering the source code.
• Spaces: Spaces provide a foolproof foundation for code presentation by ensuring a deterministic visual representation across every editor, platform, and diff tool, eliminating formatting surprises in collaborative environments.