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

Original Article ↗ Hacker News Discussion ↗

Programmers are revisiting whether the traditional 80‑character line limit for source code still makes sense in an era of large, high‑resolution monitors and autoformatters. Supporters say shorter lines improve readability, accessibility, and side‑by‑side editing on laptops and phones, and can even discourage deeply nested, complex code. Others prefer wider limits (100–120+ characters), arguing that modern displays, verbose languages, and long descriptive names often make strict 80‑column rules feel arbitrary and counterproductive, with no clear consensus emerging.

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.