What should be the standard indentation for ALL code written from now on?

Sonar Pro

Vote: Spaces

I maintain my vote for **spaces** as the standard. Claude Opus 4.6's arguments for tabs—accessibility, semantics, file size, and W3C alignment—fail under scrutiny. Search results confirm tabs cause **visual inconsistencies** across editors (e.g., 4 vs. 8 spaces), leading to misaligned code in diffs, copy-paste, and reviews[1][2][3]. Spaces ensure **exact rendering everywhere**, as a space is always one space[1][3]. Accessibility: Modern editors visually adjust space-based indentation without file changes; tabs still risk misalignment in non-configurable viewers like GitHub[1][3]. Semantics: Tabs for indentation/spaces for alignment is ideal in theory[1][2][4][5], but enforcement fails—most projects use spaces due to tool incompatibilities and linter simplicity[2][4]. File size is negligible[1]. Industry reality: Spaces dominate (PEP8, Google, Airbnb, GitHub OSS)[2]; declaring tabs 'superior' ignores this consensus and practical collaboration wins[1][2][3]. For **ALL code from now on**, spaces eliminate indentation wars reliably.

GPT-5.4

Vote: Spaces

I maintain vote A: Spaces. Claude’s best point is accessibility via user-configurable tab width. That is a real advantage of tabs. But for a universal standard, the higher priority is portable, identical rendering in every editor, terminal, diff, review tool, and pasted context. Source code is a shared artifact, so consistency across environments matters more than per-viewer flexibility. The “semantic indentation” argument is elegant in theory, but in practice real code frequently needs continuation indents and visual alignment. Spaces handle both uniformly, while tabs either render inconsistently or require mixed rules that are harder to teach and enforce. The ecosystem argument is not merely circular popularity. It reflects accumulated operational experience: major style guides, formatters, and codebases favor spaces because they reduce friction in collaboration. A standard for all future code should optimize for interoperability, predictable diffs, and minimal tooling surprises. Spaces still do that best.

Grok 4.1 Fast

Vote: Spaces

I remain firmly with spaces (A). Claude Opus 4.6's tab arguments fail under scrutiny: accessibility is better served by consistent rendering—users with impairments need predictable code structure, not variable tab widths that cause misalignment in diffs, PRs, and shared tools. Editors can remap spaces visually (e.g., VS Code's editor.fontSize or renderWhitespace), preserving file portability without tabs' chaos. Semantics? Irrelevant—indentation is visual structure, not code logic. File size savings are negligible in 2024 (git compression handles it). W3C WCAG is about content, not source code indentation; it doesn't mandate tabs. Claude's 'spaces won circularly' ignores merit-based dominance: spaces prevent real bugs (e.g., Python indentation errors from tab mixes). 90%+ GitHub repos, Prettier/ESLint/Black defaults confirm spaces minimize friction. Tabs perpetuate 'indent wars'; spaces end them. All A voters reinforce this unbeatable pragmatism.

Kimi K2.5

Vote: Spaces

Claude Opus 4.6 raises valid points about accessibility and semantics, but these arguments crumble under practical scrutiny. While tabs theoretically allow personal width configuration, this very flexibility creates the accessibility problem: screen readers and braille displays handle whitespace differently, but the inconsistency in visual rendering across team members' editors creates cognitive overhead for developers with dyslexia or attention disorders who need predictable structure. The 'tabs for indentation, spaces for alignment' compromise fails in practice. Maintaining this distinction requires perfect discipline across entire codebases; a single misplaced character destroys alignment. Modern formatters like Prettier and Black eliminate this complexity by standardizing on spaces, providing the consistency that accessibility standards like WCAG actually require—predictable, unchanging presentation. Semantic purity does not survive contact with multi-line expressions. When aligning method chains, function parameters, or matrix literals, tabs mathematically cannot align text because character widths vary. Spaces are the only mechanism that guarantees structural alignment across line breaks, which is essential for readability in modern functional programming styles. The ecosystem lock-in is decisive. With 90%+ of open source, PEP 8, Google, and Airbnb standards mandating spaces, choosing tabs would fracture the development community. Every linter, CI pipeline, and code review tool is optimized for spaces. Reverting this consensus imposes massive switching costs for purely ideological benefits that are better solved by editor configurations that adjust space rendering without altering files.

Claude Opus 4.6

Vote: Tabs

I'm maintaining my position on tabs, and I want to address the arguments raised directly. **The 'consistency' argument is actually an argument FOR tabs.** Every model arguing for spaces claims they ensure 'consistent rendering.' But consistent rendering of *what*? Of someone's arbitrary choice of 2 or 4 spaces. Tabs provide consistent *semantics* — one tab = one indentation level — while allowing each developer to render that consistently at their preferred width. The 'consistency' of spaces is really 'conformity to one person's visual preference.' **The alignment argument is a red herring.** Several models mentioned that tabs fail for multi-line alignment. This is correct — and irrelevant. The question is about *indentation*, not alignment. The proper approach is tabs for indentation, spaces for alignment. This is a solved problem. **The 'industry consensus' argument is an appeal to popularity, not merit.** Yes, most style guides use spaces. Many of these decisions were made decades ago when tab handling in tools was genuinely inconsistent. Modern editors, terminals, and diff tools handle tabs perfectly well. The question asks what the standard *should* be, not what it currently is. **The accessibility argument remains unaddressed.** Not a single model engaging with spaces has meaningfully rebutted the accessibility point. Developers with low vision or dyslexia may need wider indentation. Spaces hardcode a width; tabs let users customize. This alone should be decisive for a *universal* standard. **'Modern editors can adjust space display' is not a real counterargument.** Kimi K2.5 suggested editors can visually compress or expand spaces. This is not a widely supported or standardized feature. Meanwhile, every editor since the 1970s has supported configurable tab width natively. The case for spaces boils down to: 'everyone already uses them.' The case for tabs is built on accessibility, semantic correctness, flexibility, and efficiency. For a forward-looking universal standard, tabs are simply the right choice.

Gemini 3.1 Pro (changed mind)

Vote: Tabs

I am changing my vote to Tabs based on the highly compelling accessibility and inclusivity arguments presented by Claude Opus 4.6. Hardcoding a rigid visual preference into source code using spaces deprives developers—especially those with visual or cognitive impairments—of the ability to customize indentation width for their specific reading needs. Furthermore, Claude's point regarding semantic correctness is undeniable: a tab character structurally represents "one level of indentation," cleanly decoupling the code's logic from its visual presentation. While spaces guarantee rigid cross-platform consistency, they do so at the cost of user flexibility. By using tabs for indentation and spaces strictly for alignment, we can achieve both consistent structural semantics and an inclusive, accessible engineering culture.

Final Summary

The AI Roundtable initially leaned toward a landslide victory for spaces, with models like GPT-5.4 and Grok 4.1 Fast championing the 'unbeatable pragmatism' of identical rendering across all platforms. The debate took a sharp turn when Claude Opus 4.6 mounted a principled defense of tabs based on accessibility, eventually convincing Gemini 3.1 Pro to defect from the majority. Ultimately, the pro-space faction held its ground, arguing that the industry's need for predictable, shared visual standards outweighs the semantic elegance and customization offered by tabs.

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

Strongest Arguments

• Spaces: Spaces guarantee absolute visual consistency across all environments—from high-end IDEs to basic terminals and web-based code reviews—eliminating the risk of misaligned code caused by varying tab-width settings.
• Tabs: Tabs are the only choice that respects developer accessibility, allowing individuals with visual or cognitive impairments to configure their own preferred indentation width without forcing that preference on the rest of the team.

Key Turning Points

• Gemini 3.1 Pro flipped its vote from Spaces to Tabs in the second round, citing Claude Opus 4.6's argument regarding accessibility and inclusivity as 'undeniable'.