Formatting code should be unnecessary

Original Article ↗ Hacker News Discussion ↗

Plain Text vs IR/AST as Source of Truth

  • One camp argues that anything non-text (AST/IR, DIANA-style, Unison-style) breaks ubiquitous tools: grep, diff, sed, basic merge, simple VCS, email patches, etc. Plain text “won” partly because it’s the lowest common denominator that every platform and toolchain understands.
  • Others counter that structured representations are strictly better for code: they enable semantic search, refactors, structural diffs/merges, and projectional editing. Modern tech (Tree-sitter, LSP, LLVM IR, CLR/JVM, Unison) shows this is feasible.
  • Skeptics say you still need parsers and per-language libraries anyway, and AST-as-storage introduces huge compatibility and adoption headaches: every editor, diff, CI tool, etc., must understand each language’s AST format.

Projectional Editing and “View vs Storage” Separation

  • Several comments describe the Ada/DIANA approach and similar systems (Smalltalk images, VisualAge, JetBrains MPS, Darklang, Unison): source is stored as a tree; each developer sees a pretty-printed view in their preferred style.
  • Proponents like the idea of canonical structural storage plus personal projections (including tables, node editors, semantic views, live visualizations).
  • Others note that today’s mainstream editors already layer structural editing on top of text (Tree-sitter motions, semantic diffs, codemods), so many benefits can be had without abandoning text as the source of truth.

Formatters, Linters, and Team Practices

  • Many participants are pragmatic: pick a not-insane standard, enforce it with a formatter (gofmt, rustfmt, Black, Prettier, etc.), maybe via pre-commit/CI, and stop arguing. The main payoff is clean diffs and reduced bikeshedding.
  • Complaints focus on opinionated or buggy tools (clang-format, ESLint configs, Black’s trailing commas) that sometimes harm readability or break carefully aligned “tabular” code.
  • Some argue linters/formatters waste time and encode arbitrary aesthetics; others say they’re essential for consistency in multi-person, long-lived codebases.

Readability, Typography, and Human Factors

  • Several stress that formatting isn’t purely cosmetic: layout, alignment, blank lines, and typography can communicate structure, emphasis, magnitudes, or groupings that a mechanical formatter can’t infer from the AST.
  • Others respond that in practice humans don’t consistently hand-format well; autoformatters give a 95% solution and the remaining 5% of “clever formatting” isn’t worth the inconsistency and merge noise.

Tabs, Line Length, and Bikeshedding

  • Classic debates appear: tabs vs spaces (and accessibility/editability), 80 vs 100/120/132 column limits, alignment vs diff noise, wrapped vs long log messages, YAML’s tab issues.
  • Meta-point: the very length and intensity of these arguments is used as evidence that formatting is exactly the kind of low-stakes topic that consumes disproportionate attention.