Is the 80 character line limit still relevant? (2008)

Original Article ↗ Hacker News Discussion ↗

Overall stance in the thread

  • No clear consensus:
    • Some say 80 is obsolete on modern displays.
    • Others insist it’s still very useful, especially for accessibility, mobile, and split views.
    • Many converge around a “slightly wider” standard: ~100–120 chars.
    • A smaller group prefers no hard limit, using soft-wrap and judgment.

Arguments for keeping ~80 characters

  • Fits side‑by‑side code on laptops and smaller screens; good for split-screen and vertical monitors.
  • Helps with side‑by‑side diffs (e.g., on GitHub) without wrapping or horizontal scrolling.
  • Aligns with typography research on 50–80 character lines for readability (not counting indentation).
  • Easier to read on phones and tablets; several people regularly read code on public transit.
  • Encourages:
    • Shallower nesting and reduced cyclomatic complexity.
    • Smaller, focused functions.
    • More vertical “book-like” code flow that’s easier to skim.
  • Helps users with large fonts or impaired vision who can’t fit wide lines on screen.
  • Works better for printing, terminals, emailed patches, and minimal environments.

Arguments for longer limits (100–180+ characters)

  • Modern monitors (27", 4K, ultrawide) comfortably fit much more than 80 chars.
  • Hard 80-char limits can:
    • Produce awkward line breaks, especially in verbose languages (Java, Scala, Python).
    • Make function signatures and method chains harder to read.
    • Force extra refactoring just to satisfy style checks.
  • Many report 100–120 as a good compromise:
    • Still allows two code panes on common resolutions.
    • Reduces “ugly” wrapping of names, arguments, and chained calls.
  • Some feel that code readability is local and aesthetic; rigid numeric limits are misguided.

Soft wrapping, IDE behavior, and “what should line length really mean?”

  • Several use no hard limits and rely on soft-wrap / word-wrap.
  • Complaints that most editors only do dumb visual wrapping:
    • Breaks indentation-as-structure.
    • Obscures code’s tree/AST shape.
  • Proposed alternatives:
    • Dynamic, structure-aware folding/wrapping by the IDE.
    • Distinguish viewport width from “logical” line length.
    • Limits that ignore indentation (e.g., 80 chars of text + indentation).

Formatters, consistency, and tooling

  • Strong support for autoformatters (gofmt, Prettier, Black, rustfmt) to stop “formatting tennis.”
  • Some teams:
    • Enforce formatter defaults via CI.
    • Discourage custom configuration to avoid bikeshedding.
  • Tension remains where formatter defaults (e.g., 80 columns) clash with developers’ taste or language idioms.

Naming, complexity, and readability trade-offs

  • Long descriptive names can easily exceed 80 chars once indentation and expressions are included.
  • One view: if you hit 80 often, your names and/or design are too complex; refactor and shorten.
  • Opposing view: longer names reduce backtracking and cognitive load; 100–120 is needed to keep code expressive without excessive breaking.