The Best Line Length

53 points by rbr


hobbified

I think the sweet spot is more in the 100-120 range, and I have an argument.

Code is (in the best practices of practically every language) block-indented. That means we're moving the left margin to the right, and that "comfortable reading span" doesn't start at column 1. Suppose you're writing something like Java, where 99.9% of code is in a method, and every method is in a class. That means you have two levels of indentation just to get started. Write a loop and put a conditional in that loop, and you're up to four. I go for four-column indents myself, so that means 16 columns spent on whitespace, but there are people out there who believe in 8-column tabs, so that'd be 32. Practically half your allocation if you're sticking to 80.

ambv

I'm the original creator of the Black auto-formatter.

When I worked at Facebook, we used to run linters with the line length configured to 80 characters. If you went 81, the linter would complain, and that would block landing your diff. It would slow everybody down because of one character, which even our legally blind coworkers said made no difference for them in terms of readability. So in 2016 I went and created rule B950: Line Too Long in flake8-bugbear. This rule would only complain if you went more than 10% over the configured line length. flake8-bugbear’s docs tell the whole story, but all we need to know now is that this made the effective allowed line length 88 characters.

Years passed. It turned out people really liked the rule, mostly because they didn’t even notice the change. They just quietly stopped being annoyed by the overzealous linter, and the source code silently grew those few extra characters per line. So when time came to embrace auto-formatting in 2018, I had a decision to make: do I format to the 80 characters that people thought their projects limit the length, or do I format to 80 + 10%, which is the effective length anyway? I decided to do the latter, and since it seems to work so well (see Raymond Hettinger's "Beyond PEP8" talk where he advocates for 90ish), I made it the default. At the time, I even tested reformatting large numbers of files internally with 79, 80, 85, 88, 90, 92, ... up to 100 and found that after 88 there wasn't that much change in the number of lines being blown-up due to the expression being longer than the allowed line length.

To be very explicit. A few people over the years complained that this innocent number is a Nazi dog whistle. It is not. My family suffered during World War II. Fuck Nazis, fuck antisemitism, fuck xenophobia.

When I developed the default, I was entirely unaware that this connotation exists. I chose the number due to the reasons above, and also because two eights look cute together, and it’s like a double infinity. I refuse to let a fringe group take over a two-digit number. Don’t let them. It’s just a functional number.

susam

I read the entire article hoping to find some kind of justification for the ideal line length. The answer is:

The exact, specific number here is still ultimately a matter of personal preference.

So yes, the title is bait and the bait worked on me. However, there are some interesting points in the article, so it is probably still worth a read.

These days, most of the displays I work on can easily fit around 540x140 characters with the default settings (say on a 27-inch display). I do not like how horrendously tiny everything looks at that scale, so I usually adjust it to fit only about 270x70 characters instead. For hobby code that I write for myself, I usually, though not always, restrict line length to 70 characters. This conservative limit comes from the default fill-column value in Emacs. It also lets me open three files side by side in split windows, which is a nice bonus. In professional work, I have noticed that most people around me seem to prefer a limit of around 100 or 120 characters. That works for me too. I am not particularly dogmatic about this kind of stuff.

The article links to Dan Luu's website as an example of a site that is, in their words, 'extremely, almost unreadably bad'. But I find the brutal simplicity of Dan's website actually endearing. Also, I am not sure if it is extremely or almost unreadably bad. I can read that website just fine. I should admit that I usually open it in a narrow window, which fits well with how I normally browse the web.

I tend to keep two browser windows open at all times. One uses the full width of the screen and the other is set to the minimum possible width. This is just a quirk of my browsing habits. As a hobby, I often work on my own website as well as small web-based tools and games, so I like to check how things look in both wide and narrow viewports, so it is no trouble for me to move 'brutalist' web pages into the narrow window. And these days, there's reader mode too. I realise not everyone is willing to do this, so brutalist websites don't work well for everyone.

As an aside, I was very fond of the 80x25 and 80x24 text displays from the old days of computing. This was the era of MS-DOS on IBM PC compatibles and Unix systems with VT100/VT220-style terminals. I absolutely loved working with those systems. Text user interface applications such as EDIT.COM, the Borland IDEs, and others from that era were tailor-made for those displays. They were my gateway into the world of computing.

So when I installed a modern Linux distribution in the early 2000s and discovered that the console had much larger dimensions than 80x25, even on /dev/tty1, I found it visually disturbing. I was so used to the 80x25 layout that the extra space felt overwhelming and distracting. For a long time, I went out of my way to implement workarounds just to get back my familiar 80x25 display. Eventually, I got used to the larger dimensions and embraced them. But I often wonder whether anyone else had a similar reaction to higher-resolution text displays.