Why 80 Characters? The Line-Length Tradition

#webdev #tutorial

Open almost any linter config and you will find a setting like max-line-length: 80. Nobody in the room chose 80 on purpose — it was inherited, and the chain of inheritance runs back nearly a century to a piece of cardboard.

Where the Number Comes From

The 80 in "80 columns" is the width of the IBM punched card. The card layout that became the industry standard held 80 columns of data, each column representing one character. When programmers fed instructions into early computers, one card was roughly one line of code, and that line could be at most 80 characters wide. The number was a physical constraint of a paper artifact.

When interactive terminals replaced card readers, the 80-column habit came along. Influential text terminals — the DEC VT100 being the famous example — defaulted to an 80-column-by-24-row display. That choice was not arbitrary either: building terminals that matched the existing 80-column world of cards and line printers kept everything compatible. Software written for cards still fit on screen, and printouts still lined up.

From there the convention propagated upward through the whole stack. Editors assumed 80 columns. Print routines wrapped at 80. Style guides codified it. By the time anyone could buy a monitor wide enough to show 200 characters, "keep lines under 80" was already baked into the culture, the tooling, and a generation of muscle memory.

The specific number 80 is a leftover from punched-card hardware that no living developer has ever touched. What kept the convention alive after the hardware vanished is that it happens to align with how people actually read code and review diffs — so a constraint born of cardboard turned into a genuine readability guideline.

Why It Survived the Hardware

If 80 were only a hardware relic, it would have died with the VT100. It persists because narrower lines carry real, ongoing benefits.

The first is plain readability. Just as newspapers and books use narrow columns, short lines are easier for the eye to scan; you do not lose your place tracking back across a very wide line to find the start of the next one. Prose typography and code share this ergonomic fact.

The second is fitting things side by side. A capped line width lets you place two files next to each other, view a split pane, or read a diff with old and new versions in adjacent columns — all without horizontal scrolling. Code review tools lean heavily on this. A 200-character line that has to wrap or scroll inside a narrow diff column is genuinely harder to review.

# Fits in a narrow diff column, reads cleanly side by side:
def total(items):
    return sum(item.price * item.qty for item in items)

The third benefit is subtler: a line limit acts as a quiet pressure against over-nesting. When deeply indented code keeps bumping into the right margin, that friction nudges you to extract a function or flatten the logic. The limit becomes a soft signal that complexity is creeping in.

80, 100, or 120?

The 80-character rule is no longer universal. Modern screens are wide, names are longer and more descriptive than they were in the punched-card era, and many teams have decided the original number is too tight. A common compromise is 100; another is 120. Several language ecosystems and auto-formatters ship with their own defaults — some near 80, some closer to 100 — and the practical answer is usually "whatever your formatter enforces, applied consistently."

The point that outlives the exact number is the principle: pick a limit, let a tool enforce it automatically, and stop arguing about it in code review. Whether you land on 80, 100, or 120 matters far less than having a single agreed line that keeps diffs reviewable and discourages runaway nesting.