David's Blog

I think lines of code should be no more than 80 characters long. Just about everyone disagrees with me, which is how I know I’m right.

Kidding aside, this is my argument:

1. The optimal line length for reading is 45-75 characters.
2. We should optimize code for reading, not writing.
3. On average, code is offset by ~4 chars of whitespace.
4. Hence, we should have at most ~80 character line limits.

This is not just personal preference. It is based on experimentally-verified features of our psychology, as well as usage patterns in 1.8 trillion lines of open source code. An 80 character line limit will produce better software than a 100, 120, or greater character limit – software that’s easier for engineers to read and quicker for them to understand.

The Argument Against 80 Character Lines

These days it’s an unpopular¹ view that lines of code should be at most 80 characters long. Many see it as an outdated artifact of the days when code was written on punch cards. No less than the immortal Linus Torvalds holds this view. As he gently puts it:

Excessive line breaks are BAD. [. . .] [M]any of us have long long [sic] since skipped the whole “80-column terminal” model. [. . .] Longer lines are fundamentally useful. My monitor is not only a lot wider than it is tall, my fonts are universally narrower than they are tall. Long lines are natural. [. . .] I do not care about somebody with a 80x25 terminal window getting line wrapping. [. . .] People with restrictive hardware shouldn’t make it more inconvenient for people who have better resources. [source]

The prevailing argument for abandoning the historic 80-character limit seems to boil down to this:

1. The only reasons we had for 80-character limits no longer apply.
2. We have big monitors now, and long lines are useful on big monitors.
3. If there are no good reasons to have such a limit, and good reasons to not have it, then we should not have it.
4. Therefore, we should not have an 80-character limit.

Call this “Linus’ Argument”. It is a valid argument – if its premises are true then its conclusion must be true as well – so it should be taken seriously. But are all of its premises true?

Against Linus’ Argument

No. The first premise is false. There are strong reasons to have 80 characters – or even fewer – as one’s line limit. And they are as strong today as they were in the days of punch cards.

Against the first premise there are decades of research on the psychology of reading. And it directly contradicts what Torvalds says about long lines being “natural”. This article is a very good summary.

We know that people don’t read each individual word. Instead, they use their foveal (or central) vision to focus on a word, while using their peripheral vision to find the next spot on which to focus. [. . .] We also know that people don’t fixate on every word, but tend to skip words (their eyes take little leaps, called “saccades”) and fill in the rest. [. . .] [W]e know that readers anticipate the next line while moving their eyes horizontally along a line; so, their eyes are drawn down the left edge of the text. [source]

These properties of our psychology make long lines particularly problematic. If we read by focusing on every few words and inferring what’s in between, there is a real cost to having long lines which pull our eyes away from the rest of what we’re reading. And if we find the next spot on which to focus using peripheral vision, we pay a price for long lines that put the next focus point outside of the periphery.

As the article continues:

“Reading a long line of type causes fatigue: the reader must move his head at the end of each line and search for the beginning of the next line.” [. . .] If a casual reader gets tired of reading a long horizontal line, then they’re more likely to skim the left edge of the text [potentially missing important information at the end of the line]. If an engaged reader gets tired of reading a long horizontal line, then they’re more likely to accidentally read the same line of text twice (a phenomenon known as “doubling”). [source]

In summary, long lines:

1. Cause greater fatigue
2. Result in more reading errors
3. Make it easier to miss important information
4. Make it harder to find desired information
5. Waste time (via "doubling")

The downsides of long lines were famously observed in a pair of eye-scanning experiments done on Google’s search interface². In the experiments, people were given the Google search results displayed in either its 2005 or 2015 interface and asked to find a specific piece of information.

Here are the resulting heatmaps showing where on the page people looked:

(Image Source: Google Golden Triangle Research: Eye Tracking Study; The Evolution of Google’s Search Results Pages & Effects on User Behavior)

The people given the 2005 version of the interface initially wasted time reading the entire lines at the top, then began quickly skimming the left hand column. In the 2015 version, with a shorter line length, people were able to more quickly assess whether or not a given result was what they were looking for and move on if it wasn’t.

The eye tracking demonstrated that people scanned the entire page quickly down the left side to examine Google’s updated categories. [When Google reduced the line length on their search results] [t]here was significantly less horizontal scanning compared to the 2005 study. In fact, the amount of time it took participants to find a desirable result decreased from the 05’s study average 14-seconds to the new study average 8-9 seconds. [source]

It took people fully ~40% less time to find what they were looking for with shorter lines. How short? The lines in Google’s 2015 interface were approximately 85 characters long.

I think it’s obvious that we want to optimize for each of (A)-(E) above when it comes to software engineering. We want to make our code as easy as possible to read correctly. We want engineers to find what they’re looking for as quickly as they can and to avoid unnecessary errors. In all of these respects, long lines are bad.

So it’s simply not true that the “only reasons we had for 80-character limits no longer apply”. As such, the argument is valid but unsound, and its conclusion doesn’t follow.

The Positive Case for 80-Chars

So far I’ve made a strictly negative case against “long” lines. But, as the previous section might suggest, I think we can go further and actually make a positive argument for 80 character line limits. It goes like this:

1. The optimal line length for reading is 45-75 characters.
2. We should optimize code for reading, not writing.
3. On average, code is prefixed by ~4 chars of whitespace.
4. Hence, we should have at most ~80 character line limits.

If you have doubts about the first premise, spend 2 minutes googling “optimal line length”. You will quickly find that in Typography – the domain that actually studies this and performs eye-scanning experiments – the resounding consensus is 45-75 characters. For instance:

65 characters (2.5 times the Roman alphabet) is often referred to as the perfect measure. Derived from this number is the ideal range that all designers should strive for: 45 to 75 characters (including spaces and punctuation) per line for print. [source]

Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. [source]

The length of a line should be comfortable to read: too short and it breaks up words or phrases; too long and the reader must search for the beginning of each line. If you are uncertain about line length, a good rule of thumb is to set the type with 35 to 70 characters per line. [source]

The optimal line length for body text is 50–75 characters [source]

[I]t is widely accepted that line lengths fall between 45 and 75 characters per line (cpl), though the ideal is 66 cpl (including letters and spaces). [source

This should speak for itself.

My reasons for the second premise are straightforward. Code is written once but read many, many times. We read code far more than we write it. In a long-lived codebase, for example, code that is written over the course of a couple hours might be read-only for the next decade. And usually the people who read it are not the people who write it – meaning we want to make it as easy as possible for people to discover (rather than remember) its meaning.

The Problem of Indentation

At this point there is an obvious objection: most code is prefixed by indentation. And in some languages (e.g. python) indentation actually has a meaning, so our line limits have to make room for it. Hence, even if it’s psychologically optimal to have short lines, we need to account for the fact that most code is not going to be able to start at the left edge of the screen.

This cannot be denied. But how much whitespace on average prefixes a line of code?

The average matters because we shouldn’t be purists when it comes to line limits. A line of code can exceed the limit if there is good reason. What we want is just a rule that is going to work in the vast majority of cases. With that in mind, it seems that a reasonable line limit would be equal to the high end of the optimal reading range – roughly 75 characters – plus the average amount of indentation in the language.

As it happens, it’s possible to get a reasonable approximation of the amount of indentation in professional codebases for a given language. In 2016, Github released a set of public BigQuery tables to allow people to easily write SQL against the code in public GitHub repositories.

I wrote a query against this data for the most popular languages to find out how much indentation they have on average per line.³ Here are some of the results:

* = includes indentation

The query excluded things like binaries, auto-generated files, build-artifacts, minimized files, data files, non-text files, empty lines, and anything that didn’t look like it was written, or intended to be consumed, by a human.

After all of these filters were applied, the query ran against 1.78 trillion lines of open source code in the 19 most popular languages, and found that there are on average only 4.1 spaces of indentation per line and ~35 characters per line total.

Interestingly, in no case did the average amount of indentation for a language require that that language have greater than 80 character line limits in order to accommodate the 45-75 character ideal range prescribed by the psychology of reading.

Put another way: indentation does not take up all that much space on most lines. We can use indentation and still comfortably remain within 80 characters the vast majority of the time.

The query did reveal, however, that an 80-character limit would be disruptive. Among the most popular languages, only one (C) had a p-99 line length that was under 80 characters. This means that in most languages, at least 1% of the lines in open source code are longer than I’m arguing they should be. If any of these projects were to adopt an 80-character line limit, >1% of the lines would have to change.

This isn’t surprising. Again: programmers like to write long lines. It is the default preference in the age of big monitors. I never said that an 80 character limit wouldn’t have consequences. But I want to emphasize that those consequences aren’t the end of the world. I have written code in 9 of the 19 most popular languages professionally – more than that if you include hobby projects. In every single one of them without exception it has been possible to write expressive, functional code in under 80 characters per line. Even SQL, which had far-and-away the highest p99 line length, can be comfortably written within these limits. As evidence, I submit the very query which produced the data above.

Objections

Objection 1. Reading code is just not the same thing as reading prose in a book or even reading Google search results. It’s not a natural language. So the lessons learned from reading natural language do not apply here.

Fair. Code is obviously not prose. But there have also been eye scanning studies done on programmers⁴ (albeit not as many). And they validate what was said above – namely, programmers likewise jump from point to point when they read code, inferring what’s in between, and use their peripheral vision to guide them in determining where to focus next.

This is a representative study, with full text available here (at the time I am writing). They include one figure of the IDE with a “representative [eye] scan-path superimposed”. Here it is:

Notice how the programmer’s eyes jumped around. When reading the code, they focused on discrete points in the line – often only one point per line: the center. This strongly suggests that inference and peripheral version were being used to fill in the rest of the information: two processes that long lines disrupt.

It’s not surprising that programmers would read code the same way people read everything else. This is just the way our eyes and brains work. We have a small nerve cluster in our retina that only allows us to focus narrowly. With this limitation, the most efficient way to read anything is to jump from point to point and fill in the blanks. It’s just a consequence of our biology.

Objection 2. When code is stretched out vertically it’s actually difficult to read/understand.

I admit it takes some getting used to if you’re accustomed to writing code that can be longer. But once you are used to it, it actually usually helps in understanding the code – especially when you’re reading code that you did not write (which, again, is what we should be optimizing for).

Just consider these examples. Which one is easier to understand?

LENGTH(REGEXP_REPLACE(REGEXP_REPLACE(c.content, r'\t', ' '), r'(\n|\r|\v){2,}', '\n')) as cleaned_content,

VS. the same code broken up so it’s under 80 characters per line:

LENGTH(
  REGEXP_REPLACE(
    REGEXP_REPLACE(c.content, r'\t', ' '),
    r'(\n|\r|\v){2,}',
    '\n'
  )
) as cleaned_content,

I’ll bet the second one was simpler to understand.

What is an input of what in the first one? You can probably figure it out, but it’s emphatically not obvious if you didn’t write it. The second one is much more forthcoming about its meaning.

I think the problem here is that most engineers are optimizing for writing code. This is completely natural. When you’re writing the code, your intent is perfectly clear to you. But this just isn’t the case for anyone reading your code. We need to be thinking more about the experience of those people.

Objection 3. Vertical code just wastes space on my screen.

Then you don’t have enough panes open in your editor! Narrow code on a wide monitor is amazing. You can often have 3 or 4 vertical splits in your editor (in Vim I sometimes have multiple splits for different parts of the same file), allowing you to quickly consult other parts of the codebase. It is incredibly helpful.

Conclusion

I think that the three premises of my argument are true, and that its conclusion follows. We should have 80-char line limits even now, in this brave new world of readily available, wide screen monitors. Even if it is more fun or more convenient to write code with lines that are longer than 80 characters, the benefits of shorter lines on reading far outweigh this.

Having such limits does not mean that they should never be exceeded. It just means that the burden of proof should be on anyone who wants to exceed them. The linter should yell and we should have to explain ourselves.

There certainly are instances in which exceeding an 80-character limit is justified. Having 80 character limits just means taking seriously the facts about our psychology and the languages we use, and then writing code in a way that optimizes for them.

Footnotes

[1] Some good examples of the high-quality discussion this topic has seen: 1, 2, 3

[2] For more info, see: 1, 2, 3

[3] You can view and re-run my query here . If you don’t already have one, you will have to create a (free) Google Cloud project to do this. Running the query costs about $30, which can usually be done for free with a trial account. If that’s too much work, I also put the code in a public gist, and saved it to the repo for this blog.

[4] Here are some eye tracking studies on programming if you’re interested in reading further: 1, 2, 3