80 Characters per Line Is a Standard Worth Sticking to Even Today

https://nickjanetakis.com/blog/80-characters-per-line-is-a-standard-worth-sticking-to-even-today

by ColinWright • 7 years ago

50 47 7 years ago

nickjanetakis.com

ChrisRR2• 7 years ago

You can tear my 120 character line width from my cold dead hands.

ncmncm3• 7 years ago

Cold dead hands won't be writing any more unreviewable code.

ChrisRR2• 7 years ago

You can fit 120 characters side-by-side on a 1080 monitor no problem (and I regularly do)

smt88• 7 years ago

This isn't too hard in some languages and I prefer it, but there are other languages (like C#) where class names are long and descriptive (e.g. ImmutableSortedDictionary) and it becomes harder to read instead of easier.

noblethrasher• 7 years ago

C# offers a way to mitigate that, somewhat.

I often have something like this among the top level `using` statements.

    using FooMemo = System.Collections.Immutable.ImmutableSortedDictionary<string, Foo>;

alok99• 7 years ago

You can do similar in C++. The problem is when the number of long types and variable names grows, you end up with classes and functions full of `using`, which gets confusing fast.

WorldMaker3• 7 years ago

Also `var` is such an important mitigatory for this in C# that it continues to astound me that some of the worst offenders also eschew `var` in C#. You really don't need the redundancy of `ImmutableSortedDictionary<string, Foo> localCache = new ImmutableSortedDictionary<string, Foo>()`, it's not some sort of Prolog assertion where the strict tautology makes different code than `var localCache = new ImmutableSortedDictionary<string, Foo>()`.

shermanyo• 7 years ago

^ Your line of code is 85 characters though.. Would you bother to split this line somewhere? (if trying to conform to an 80char limit)

guitarbill3• 7 years ago

We also enforce this. Not for personal or aesthetic reasons, but to keep code reviewers sane and let them review code side-by-side (as many devs do) when they might not have an ultra-wide monitor available.

ncmncm3• 7 years ago

Anything that makes code review harder or less comfortable is deeply destructive to code quality.

It is entirely hard enough to get people to do meaningful review without kneecapping them by obliging them to side-scroll just to see what changed.

quink• 7 years ago

Unified diffs beat side-by-side the majority of the time IMO.

dkersten• 7 years ago

I disagree. I personally find side-by-side easier the majority of the time (although for some cases, unified is easier, eg when I have a single line with a word or character changed).

u801e3• 7 years ago

I personally find the output of diff with the -e option most readable ;)

rightbyte• 7 years ago

What tabsize do you enforce and how many meetings were it before a number was agreed upon?

guitarbill3• 7 years ago

Doesn't matter. What matters is consistency in the repo. To this effect, it's important the CI process enforces it - code reviewers could never do it, and it's a waste of their time. I highly recommend auto-formatters like Black, Prettier, Gofmt, etc. They take so much cognitive load off devs and reviewers, it's completely worth it. (In practice, this means whoever sets up the CI process gets to decide :P)

kevindong• 7 years ago

In code, enforcing a max character count per line is debatable and has some merit.

In prose (i.e. documentation written in Markdown), I'd say that enforcing a max count is definitely counterproductive. Prose is meant to start a new line whenever it's needed. What you write in Markdown is not necessarily how it'll get formatted on a web page (i.e. even if your input is capped at 80 characters per line, the output might not necessarily be capped at 80 characters per line) since display fonts typically aren't monospaced. Consequently, the text in one line in your .md file will not necessarily show up as one line in the webpage (in fact, it probably won't).

ncmncm3• 7 years ago

Can you explain how any of the above connects to anything else? If the markdown text will be reformatted for display, you get no benefit from writing it in a wider format than allows more than one source document to be on the display at once.

You seem to be saying that when writing markdown you have no need to refer to anything else?

rhn_mk12• 7 years ago

you get no benefit from writing it in a wider format

Putting unlimited characters on a line is not merely a "wider format". It's a way of saying "format it as wide as you like", therefore the benefit is not in having a wider format, but one that simultaneously wider and narrower, depending on what's needed.

  To help visualize the benefit, abolishing line length in
  prose prevents
  lines from breaking in unexpected places, when the user's
  display is
  narrower than the preformatted text line. I find it
  extremely jarring.

With almost every editor today being able to word wrap, this stops being a problem.

While line lengths may be significant for code, where limiting "sentence length" may be useful, prose is an entirely different thing to read.

paulrpotts• 7 years ago

When I write in Markdown, I generally just turn on soft wrapping in my text editor and just make each paragraph one line.

Editing plain text using my favorite font, Bistream Vera Sans Mono 12, on a 1920x1080 display, lines break about the 150th column. That width seems to work reasonably well for me when writing blog posts.

nojvek• 7 years ago

Vscode does an autowrap maintaining the indent. So you can have it at any number.

I don’t get the 80 char width fanatics. I like long lines. I want my editor to format it based on my screen width.

80 breaks my flow.

marssaxman• 7 years ago

That's great if you are working alone or on a team where everyone agrees on the same editor with the same auto-wrap feature. In a mixed environment, writing code that is only readable if people choose the same tools you prefer can be a bit rude.

rhn_mk12• 7 years ago

That cuts both ways. The most comfortable combo of a display and font size leaves me at 70 characters per line, making anything more wrap awkwardly. It wouldn't be a stretch to say that XX-chars limit only works if everyone else has tools that work best with XX.

gowld• 7 years ago

No, if you don't hard-wrap inside lines, then each person can use their own editor with auto-soft-wrap they like.

ThorinJacobs• 7 years ago

One reason to suggest a smaller max character count is to assist those with impaired vision. I'm highly myopic and, while my lenses correct for it, I still seem to get eyestrain when using the default font/sizes in most IDEs. Bigger-screen monitors counterintuitively seem to make this worse, not better.

I can only imagine that this would be even more important for individuals with more severe vision impairments.

RcouF1uZ4gsC• 7 years ago

The whole analysis of justifying 80 characters per line by talking about how many more windows you can place side by is problematic. The problem is that this same logic would suggest that 40 characters per line is even better because we can get in even more side by side views.

I would like to talk about the downsides of 80 characters.

First point is that most monitor configurations are wider than they are tall. When you have 80 characters for line, you are wasting a lot of horizontal space on most configurations. This is especially true with laptops.

Second, at least for me, I am focusing on 1 file most of the time. 90% of the time, I write code in 1 file, with maybe 10%, I look at 2 files. With wide lines, I can see more of my code at a glance without scrolling.

Third, when you break at 80 characters, you waste more space cause you need to indent the new lines that were broken up.

Fourth, if you use languages like Python that have semantic whitespace, you need line continuation characters that just add to the noise.

Fifth, for those cases where you are comparing code side by side, having an editor that does intelligent wrapping to make code narrower is not that big of a deal.

magduf• 7 years ago

Completely agreed. I prefer 100-character lines; with that, I have less line-breaking, and I can still easily fit two code windows side-by-side on my widescreen monitors. 120 characters would be good too, but I think anything over that yields greatly diminishing returns.

mixmastamyk• 7 years ago

I have a monitor in portrait to reduce scrolling.

u801e3• 7 years ago

When you have 80 characters for line, you are wasting a lot of horizontal space on most configurations.

But then you're requiring those who read through your code to have the window displaying your code maximized in order to avoid having it wrap or having to scroll to read it.

Second, at least for me, I am focusing on 1 file most of the time. 90% of the time, I write code in 1 file, with maybe 10%, I look at 2 files.

When viewing diffs, a lot of people like to view them side by side. In some cases, people use a tool like kdiff3 to handle merges and need to be able to see 3 copies of the file side by side.

Third, when you break at 80 characters, you waste more space cause you need to indent the new lines that were broken up.

It really depends on whether you use a lot of long variable names and/or have to include scope identifiers when referencing them. In python, a typical module may have a very small fraction of statements that require lines greater than 80 characters. That means that it doesn't add that many more lines to the file compared to just keeping those longer statements as a single line.

Fourth, if you use languages like Python that have semantic whitespace, you need line continuation characters that just add to the noise.

Not necessarily. Any opening (, [, { can effectively serve as a continuation character. So you could write a print statement like:

  print(
      'Hello there. '
      'This will be printed on a single line.'
  )

> Fifth, for those cases where you are comparing code side by side, having an editor that does intelligent wrapping to make code narrower is not that big of a deal.

For line based diffs, it does make the diff significantly harder to read in my experience (especially when looking at the source file in conjunction with the diff).

WorldMaker3• 7 years ago

One VS Code suggestion I'd mention is Centered Layout mode (under View > Appearance). If you only have one editor group open and aren't doing side-by-side work, it's a nice relaxed view of the editor that defaults to roughly 80 characters as well. (Official docs say it defaults to a golden ratio of your screen resolution, so it's not directly based on character count.)

0-_-0• 7 years ago

I prefer Zen Mode, which is similar but with only the file you're editing showing.

WorldMaker3• 7 years ago

Also, Both together is a great option. (I think the combo is often but not always the default now, depending I think on how you enter Zen Mode?)

Roboprog2• 7 years ago

Textbooks and newspapers print in multiple columns, even when using tabloid size paper, because it’s more readable.

There’s empirical evidence to back it up.

The “I have a big monitor” guys just need to stop. Please.

bnolsen• 7 years ago

I have a big monitor and fit 4 80 wide terms side by side quite nicely with a bit of room to spare (34" ultrawide 1440 monitor).

Roboprog2• 7 years ago

Edit: “I have a big monitor - and I’m going to write all the way across it”. That’s what needs to stop.

skybrian• 7 years ago

Whatever you pick, it should be a guideline and not a strict rule, so it doesn't interfere with automatic edits. Renaming a variable so that it's slightly longer shouldn't cause cascading changes.

(This is why gofmt doesn't enforce a line limit.)

When a human edits the code, they can fix it if the lines seem too long.

zapzupnz• 7 years ago

It's a good ideal, but maybe a bit short for some languages like Objective-C and Swift which use rather wordy function names/selectors; chaining them across multiple lines for the sake of hitting 80 characters per line can be much harder to read.

cosmopaladin• 7 years ago

Who doesn't use soft line wrapping?

cjbprime• 7 years ago

80 vs 120 makes it easy to declare 80 the winner, but I'm less convinced that 80's better than 90 or 100, especially for JS with callbacks. There's simply a couple extra indentation stops compared to languages like C or Go.

100 seems like a good modern take to me.

exabrial• 7 years ago

I think software is common enough in nearly every editor you not enforce limits, but instead "one thing at a time" rules.

spapin• 7 years ago

Many lines to do one things, or many things on one line, are what makes code hard to read. Not the number of letters.

anth_anm• 7 years ago

It's not, but good luck ever getting rid of it.

anotheryou• 7 years ago

css hack for hn:

   p, span{
     max-width: 60ch !important;
     display:inline-block; 
   }

(probably breaks other sites)

sfopdxnonstop• 7 years ago

No. 80 is way too narrow. Forget screen size, it's just not enough for a lot of code lines.

80 Characters per Line Is a Standard Worth Sticking to Even Today

Related Stories