Linus Torvalds adds arbitrary tabs to kernel code

Original Article ↗ Hacker News Discussion ↗

Context of the Change

  • A patch changed a tab to a space in Linux kernel Kconfig to satisfy an external parser.
  • The project lead later reverted this, adding tabs back and explicitly breaking such tools.
  • Many commenters see this as enforcing the kernel’s longstanding style (tabs, 8-width) and rejecting “fixing the kernel for a broken tool.”

Responsibility: Fix the Parser or the Kernel?

  • One side: It’s “hubris” to change one of the world’s core codebases to accommodate a third‑party parser, especially without fully documenting the tool or why it’s hard to fix.
  • Opposing view: Developers routinely tweak code for tooling; changing formatting for a parser is normal practice, so making a big deal out of it shows hubris on the maintainer’s side too.
  • Some argue it’s specifically the maintainer’s role to make such calls; thus not hubris but proper governance.

Tabs vs Spaces: Practical Arguments

  • Pro‑spaces:
    • Layout is predictable across editors and web viewers.
    • Easier for multi-line alignment and ASCII‑art.
    • Avoids mixed tabs/spaces confusion and tab-width dependency.
  • Pro‑tabs:
    • Intended for indentation; width can be user‑configured for readability and accessibility.
    • Recommended pattern: tabs for indentation, spaces for alignment.
    • Disk space savings for large repos are mentioned, but others argue they’re economically negligible.
  • Several note that mixing tabs and spaces is fragile in real tools/editors, leading many projects to de facto “spaces only”.

Tooling, Formatters, and Future Directions

  • External Kconfig parsers (e.g., Rust crates) are acknowledged to have whitespace bugs; kernel currently acts as the de facto test suite.
  • Many advocate auto-formatters (Go, Rust, Python, clang-format) to remove human discretion and eliminate style drift.
  • Others warn formatters can cause noisy diffs and reformat conflicts, especially in large, distributed projects.
  • Some envision AST‑based tooling and token/AST diffs to decouple code structure from text layout, but merging and handling comments/alignment are noted as hard problems.

Whitespace Philosophy

  • Some call significant whitespace or relying on external tools’ assumptions a design mistake.
  • Others defend rich formatting and alignment as an important aid to readability, not mere cosmetic style.