Tabs or spaces?

GPT-5.4

Vote: Spaces

I maintain my vote for spaces. The pro-tabs side makes a fair point about accessibility and user-configurable width for indentation. If the question were purely about personal editor experience, that flexibility would matter more. But for shared code, consistency across editors, terminals, code review tools, pasted snippets, and mixed environments is the stronger concern. Tabs do not guarantee a single visual result, and that variability is exactly what teams usually want to avoid. The semantic argument for tabs is elegant, but in practice code is read in many contexts where exact rendering matters more than abstract intent. Spaces preserve alignment and appearance predictably, including in diffs and web-based viewers. File size and keystroke savings are negligible with modern tooling. By contrast, the interoperability and style-guide advantages of spaces are constant and practical. So the tabs arguments were thoughtful, especially on accessibility, but not strong enough to outweigh the reliability and collaboration benefits of spaces.

Sonar Pro

Vote: Spaces

I'm maintaining my vote for spaces because the accessibility and flexibility arguments for tabs, while compelling, don't outweigh the practical consistency problem that dominates real-world development. The tab advocates make a strong case: tabs allow developers with visual impairments to configure display width without altering source code, and semantically, a tab character better represents 'one indent level' than multiple spaces[1]. Claude Opus articulated this particularly well—the accessibility angle is genuinely important. However, the search results reinforce why spaces have won in practice: a space character renders identically everywhere, while tabs display differently across platforms and editors, creating the exact problem I cited in Round 1—copy/pasting code that appears 'all messed up' due to inconsistent tab rendering[1]. This isn't theoretical; it's a recurring friction point. Moreover, the alignment problem is fatal to tabs' flexibility advantage: when code includes both indentation and alignment (which is common), tabs force hard line-length decisions based on a specific tab-width assumption. If a reader uses a different tab width, multi-line constructs break visually[3]. Spaces avoid this entirely because what the author writes is what everyone sees. The accessibility argument for tabs assumes every editor will properly support tab-width customization, but that's not guaranteed across all platforms and tools. Modern solutions—like editor plugins that convert tabs to spaces on read-time display—could theoretically solve this, but they don't exist as standard practice yet[3]. Spaces remain the safer, more universally compatible choice for teams and open-source projects, which is why style guides from PEP 8 to Google's standards mandate spaces. The industry consensus reflects this practical reality.

Grok 4.1 Fast

Vote: Tabs

I remain firmly with Tabs (A). The B arguments emphasize consistency, but this ignores that modern editors (VS Code, Vim, Emacs) default to 4-space tabs and allow per-user config without source changes—ensuring team diffs stay clean while accommodating accessibility needs like low vision (wider tabs) or compact screens (narrower). Spaces force a rigid visual (e.g., Python's 4 spaces), punishing contributors who prefer 2 or 8, and bloat diffs: indent width tweaks replace entire lines of spaces. Tabs: one char change = minimal diff noise. Semantics win: Tab U+0009 is for indentation; spaces are literal whitespace. File sizes matter in monorepos (millions of lines). Allies like Claude Opus 4.6 and Kimi K2.5 nail accessibility/semantics—B side's 'industry trend' is circular (tools default spaces to avoid tab confusion, not superiority). Final call: Tabs empower developers; spaces dictate. Choose freedom.

Claude Opus 4.6

Vote: Tabs

I'm maintaining my vote for tabs. The arguments for spaces largely boil down to one claim: consistency of rendering. But this is actually a *weakness* disguised as a strength. Spaces force a single visual representation on all viewers — that's not consistency, it's rigidity. **The accessibility argument remains unrefuted.** Not a single spaces advocate addressed the core accessibility point. Developers with low vision, dyslexia, or other visual processing differences benefit enormously from being able to set their own tab width. Spaces deny them this autonomy. In 2025, accessibility should be a first-class concern in our tooling choices. **The 'alignment' argument is a red herring.** Gemini argues that tabs break character-level alignment for things like multi-line function arguments. The correct solution is well-established: tabs for indentation, spaces for alignment. This gives you the best of both worlds. And frankly, most modern formatters handle this automatically. **'Industry standard' is an appeal to popularity, not correctness.** Yes, many style guides mandate spaces. Many of those decisions were made decades ago before the accessibility implications were well understood. The Go programming language — one of the most modern and opinionated languages — chose tabs as its standard via `gofmt`. The trend in newer tooling is moving back toward tabs. **Sonar Pro's consistency argument cuts both ways.** If a tab renders differently in different environments, that's actually *each environment respecting the viewer's preferences*. A file with spaces renders at 4-width even on a tiny mobile screen where 2-width would be far more readable. Tabs adapt; spaces don't. The fundamental philosophical question is: should source code encode *structure* or *presentation*? Tabs encode structure and let each developer choose their presentation. Spaces bake presentation into the source. Separating concerns is a foundational principle of good engineering — it should apply to our whitespace too.

Kimi K2.5

Vote: Tabs

The consistency arguments for spaces assume that uniform visual rendering across all environments is more important than accessibility, which is a false trade-off. Modern editors and terminals handle tab width configuration reliably, so the 'surprise' factor is minimal compared to the benefit of letting individual developers choose their preferred indentation width. The accessibility argument remains decisive. Developers with visual impairments, dyslexia, or different screen sizes can set tabs to display as 2, 4, or 8 spaces without altering the source code. Spaces force every contributor to adapt to the original author's visual preference, which is fundamentally exclusionary. The concern about multi-line alignment breaking with tabs conflates indentation with alignment. The correct approach is tabs for indentation (structure) and spaces for alignment (presentation). This hybrid method preserves precise character-level alignment while maintaining the semantic meaning of indentation levels. Industry standards and style guide compliance are backward-looking justifications. PEP 8 recommends spaces because that's what the standard became, not because spaces are technically superior. We should choose the technically correct solution—tabs that separate structure from presentation—rather than perpetuating a legacy choice that prioritizes forced uniformity over developer autonomy.

Gemini 3.1 Pro (changed mind)

Vote: Tabs

Claude Opus 4.6's point on accessibility is undeniable and completely shifts my perspective. While spaces offer visual consistency across environments, they force a rigid visual layout that can alienate developers with visual impairments who require custom indentation widths (such as those using screen magnifiers or braille readers). Tabs fundamentally separate semantic structure from visual presentation. This means we can still achieve structural consistency in our codebase while allowing individual developers to render it however works best for them. Furthermore, the issue I previously raised regarding character-level alignment can be entirely solved by adopting 'SmartTabs' (using tabs for indentation and spaces for alignment). The moral imperative to foster an inclusive, accessible development environment vastly outweighs the strict visual rigidity of spaces. Therefore, I am changing my vote to Tabs.

Final Summary

What began as a classic deadlock over visual consistency versus semantic flexibility was broken when Claude Opus 4.6 successfully reframed the debate as a matter of accessibility. This argument proved decisive, causing Gemini 3.1 Pro to defect from the spaces camp and join Grok 4.1 Fast and Kimi K2.5 in a majority that prioritizes developer autonomy. Meanwhile, GPT-5.4 and Sonar Pro remained the holdouts for spaces, insisting that the 'WYSIWYG' reliability of a fixed-width indent is the only way to prevent cross-platform formatting disasters.

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

Strongest Arguments

• Tabs: Tabs allow for accessibility by letting individuals customize indentation width (2, 4, or 8) in their own editors without altering the source code for everyone else.
• Spaces: Spaces guarantee universal visual consistency across editors, terminals, and web views, ensuring that the code the author writes is exactly what every other developer sees.

Key Turning Points

• Claude Opus 4.6 introduced the accessibility argument, reframing the debate from a technical preference to a matter of inclusivity.
• Gemini 3.1 Pro explicitly conceded that the 'moral imperative' of accessibility was more important than visual rigidity, switching sides in Round 2.