80-characters line length limit in 2017 (and later)

When you look at code style guidelines for many languages, you probably will find a rule telling that the line of your code should not exceed 80 characters. It is present for example in Rubocop (for Ruby), ESLint (for JavaScript), Clojure Style Guide or Linux kernel code guidelines. The question you may ask is: Why 80 characters and why should I care in 2017?

And I have heard this question hundreds of time. It was not always worded like that. Sometimes people were just freely disabling those rules in linter or increased a limit to, say, 150 characters, “because come on”. I don’t know if it is most frequently omitted style guideline. But I’m quite sure it is most misunderstood one.

Most common arguments against 80-characters-per-line rule are:

• It’s obsolete and anachronous
• We have wide monitors so why limit ourselves to such a silly low value?

Let’s take a closer look at those.

It’s obsolete and anachronous

As for this argument, a fun fact is that it’s probably true. History of having number 80 here probably dates back to 1928 (!). It was a year when IBM introduced a new design of their punch cards. It had - you guessed! - 12 rows and 80 columns.

Of course, there is no reason to base modern coding style on such an old invention. But somehow those 80 columns persevered in computer science world. Not only first video terminals had 80 columns displays (although more rows than IBM punch card’s original 12), but even standard Windows cmd.exe window could not be resized to have more columns than eighty.

In old times it was required to squeeze your code in 80 columns, otherwise it was wrapped or put outside of the screen and it wasn’t very pretty. But in general, I agree that sticking to a custom that has almost a century is not a very good point in discussing code style today.

We have wide monitors so why limit ourselves to such a silly low value?

People using this argument are very eager to quote Linus Torvalds, who wrote in 2009:

We fixed that to allow checkpatch to skip those warnings, but the fact is, the fundamnetal problem has always been the “80 character” part.

I don’t think any kernel developers use a vt100 any more. And even if they do, I bet they curse the “24 lines” more than they curse the occasional 80+ character lines.

Then he states that the limit is historical and proposes to change it to 132. So, why I think this is still wrong?

First of all having a wider screen does not mean you have more columns available for your code to be displayed. I actually don’t know anyone who would just open one file in their editor and maximize it. Usually, people prefer to have more buffers open and work with multiple files open at once. Or to have a terminal window open alongside their editor. In this case, even if you can fit 300 columns on your wide screen, you usually end up having more like 100 or less per file.

But there’s more.

Properties of the human eyes

It is a common misconception that what programmers do is mostly writing the code. What we do is actually mostly reading - not only documentation and StackOverflow, but also the code. It is said that the code is one programmer writing to other programmers, which inherently includes being read by others (probably more times that it’s being written). So, to talk about the optimal line length we should not refer to screen width or writing performance (I can write faster when I don’t have to think how to put it in less than 80 characters), but to reading abilities.

And those say, depending on the source, that optimal line length is 50, 60 or 75 characters. Of course, a paragraph text like in the book or on a website is not exactly the same as the code. But there is little to no reason to think that human eye behaves differently when reading the code.

So, what happens when the line is too long?

if a line of text is too long the reader’s eyes will have a hard time focusing on the text. This is because the line length makes it difficult to gauge where the line starts and ends. Furthermore it can be difficult to continue onto the correct line in large blocks of text.

The last sentence is probably most important: with long lines when you want to start reading the next line, you might, in turn, start reading the same one again or skip one. Both mistakes may result in misunderstanding and frustration. But there’s more.

It turns out that the subconscious mind is energized when jumping to the next line (as long as it doesn’t happen too frequently, see above bullet point). At the beginning of every new line the reader is focused, but this focus gradually wears off over the duration of the line.

And I might confirm this from my own experience. Parts of code placed at the end of a long line sometimes are just somehow omitted. And this last part may include very important parts, such as Ruby’s inline if.

That being said, the origin of 80-characters limit probably has nothing to do with scientific research about what length is best for reading. But both of them play nicely with each other. And this is the reason why you should not give up on constraining line length in your projects. Even on wide screens ;)