The Best Line Length(blog.glyph.im)
blog.glyph.im
The Best Line Length
https://blog.glyph.im/2025/08/the-best-line-length.html
52 comments
> TeX has a default of 66 characters per line.
LaTeX defaults to that, but Plain TeX defaults to 10pt font with 1in margins, which is ~100 characters per line (which much too long to be readable).
LaTeX defaults to that, but Plain TeX defaults to 10pt font with 1in margins, which is ~100 characters per line (which much too long to be readable).
Just to put in perspective, on a 1080p screen with no zooming the line length in a top level HN comment is ~200 characters including spaces. It's bearable because the comments tend to have just a few lines and a tree structure to avoid the wall of text.
The blog referenced in the article as "extremely, almost unreadably bad" clocks in at ~300 characters per line, with the classic wall of text appearance which makes it very tiring to read.
The blog referenced in the article as "extremely, almost unreadably bad" clocks in at ~300 characters per line, with the classic wall of text appearance which makes it very tiring to read.
As the article notes, code is not prose. They're totally different. (So I don't know why he talks about line lengths in prose so much; it's basically irrelevant.)
K&R uses longer lines: https://entropicthoughts.com/technical-writing-learning-from...
I wonder if technical density affects optimal line length.
I wonder if technical density affects optimal line length.
I remember a book about letterpress printing recommending one and a half alphabets. So, like, 40 characters. Or maybe it included both UC and LC, which would make it about 80.
From when trying out new fonts (and sizes) in a LaTeX memoir document:
\typeout{xlvchars is \the\xlvchars; lxvchars is \the\lxvchars}Whenever I find myself trapped in one of these arguments, I discover pretty quickly that the difference between me (an 80 cols person) and my adversary (someone much stupider) is that they're using 1 big beautiful buffer, and I have 6-8 columns of buffers side-by-side. To which I say: we both want the same things! We both want to use as much of these ridiculously wide monitors as we can. I'm doing it much better than you are. Come on in, the water is warm. :vsplit with me
Exactly. Its not about how wide the paper is, but about how many sheets fit on your desk.
Although I would recommend focusing at least one level higher than :vsplit, either at the terminal multiplexerv level or the (tiling) window manager level. Otherwise you end up wanting to run a shell in your editor... And what do you think this is, emacs?
Although I would recommend focusing at least one level higher than :vsplit, either at the terminal multiplexerv level or the (tiling) window manager level. Otherwise you end up wanting to run a shell in your editor... And what do you think this is, emacs?
Lol I'm full "macvim is the best terminal" mode; I tell everyone I know. I'm too far gone
That's exactly how I justified our 88-character code line length limit to a colleague. I split my screen into quarters and showed them how that let me keep useful context visible without having to break my focus by switching tabs/windows.
If you really want the 80 col experience, I think that was the fortran 77 default. You'd even get compiler errors if you try to exceed it. Of course there were flags to increase the line length limit but don't tell your colleagues.
Fixed-form Fortran source is 72 columns. Anything after column 72 is ignored without error as a comment.
I massively agree with tools like black and gofmt.
"Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
We need more of the same, I really wish C# had a similar opinionated tool I could use to bring dozens of company projects in line.
Something that can be run locally and in CI and has ZERO configuration, it just enforces a static style with no possibility of bikeshedding.
"Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
We need more of the same, I really wish C# had a similar opinionated tool I could use to bring dozens of company projects in line.
Something that can be run locally and in CI and has ZERO configuration, it just enforces a static style with no possibility of bikeshedding.
To everyone's detriment, gofmt doesn't wrap lines. That's why--combined with the truly evil entrenchment of tabs--lines in Go code tend to be ridiculously long. I'm not saying it's an easy problem (my info comes from Bob Nystrom's post [0] on it), but I do think it's table stakes for a formatter.
[0]: https://journal.stuffwithstuff.com/2015/09/08/the-hardest-pr...
[0]: https://journal.stuffwithstuff.com/2015/09/08/the-hardest-pr...
The "no possibility of bikeshedding" thing is critical. I like things formatted the way I format them, but the thought of having to specify and then justify and worse enforce each and every little decision just completely saps any desire I have to do any of it. Black (and isort) are huge productivity boosters. Run and done. Plus, relying on shared tools like that instead of whatever the editor does means I can hang on to Emacs for that much longer while letting other folks use whatever garbage editor they want.
Doesn't zero configuration just shift the bikeshedding from how to configure the formatting tool to which zero configuration formatting tool to use?
I'd go for the opposite. Find a highly configurable formatting tool and standardize on a particular configuration for code in your repo, and enforce this format when code is checked in.
Provide some scripts or wrappers or hooks (whatever is best for the source code control system you are using) that can on checkout automatically run that formatting tool but with a configuration supplied by the user instead of company standard configuration.
I'd go for the opposite. Find a highly configurable formatting tool and standardize on a particular configuration for code in your repo, and enforce this format when code is checked in.
Provide some scripts or wrappers or hooks (whatever is best for the source code control system you are using) that can on checkout automatically run that formatting tool but with a configuration supplied by the user instead of company standard configuration.
If you have a reliable way to get 100+ experienced programmers agree on a single style company-wide, please share =)
With a tool like black, taking it into use is a binary selection of yes/no.
Just fiddling with an .editorconfig (https://editorconfig.org) setup for a single project can take WEEKS to decide what bits to flip in which position
With a tool like black, taking it into use is a binary selection of yes/no.
Just fiddling with an .editorconfig (https://editorconfig.org) setup for a single project can take WEEKS to decide what bits to flip in which position
> The ultrawide aficionados do have a point, even if it’s not really the simple one about “old terminals” they originally thought. Our modern wide-screen displays are criminally underutilized, particularly for text. Even adding in the big chunky file, class, and method tree browser over on the left and the source code preview on the right, a brief survey of a Google Image search for “vs code” shows a lot of editors open with huge, blank areas on the right side of the window.
> Big screens are super useful as they allow us to leverage our spatial memories to keep more relevant code around and simply glance around as we think, rather than navigate interactively. But it only works if you remember to do it.
I use a single, not especially large monitor, and have worked like that essentially since I first touched a computer as a child. (Granted, today's "not especially large" monitor is much larger than the ones on the "luggable" first-generation Macs.) This is... mostly because I'm a cheapskate, but also I feel like I'd have even more trouble focusing on stuff in general with one of those massive "battlestation" setups.
And I generally keep my code inside 80 columns because I just like the aesthetic of the terminal window, and because it's an extra impetus driving my refactoring.
> Big screens are super useful as they allow us to leverage our spatial memories to keep more relevant code around and simply glance around as we think, rather than navigate interactively. But it only works if you remember to do it.
I use a single, not especially large monitor, and have worked like that essentially since I first touched a computer as a child. (Granted, today's "not especially large" monitor is much larger than the ones on the "luggable" first-generation Macs.) This is... mostly because I'm a cheapskate, but also I feel like I'd have even more trouble focusing on stuff in general with one of those massive "battlestation" setups.
And I generally keep my code inside 80 columns because I just like the aesthetic of the terminal window, and because it's an extra impetus driving my refactoring.
The problem is that on regular 13/14" laptop screens, it becomes hard to have two code editors side by side if you make the lines too wide.
And that's before we factor in all the nonsense IDEs like to clutter the screen with.
And that's before we factor in all the nonsense IDEs like to clutter the screen with.
I would probably be better off setting up a tiling window manager etc. to have two terminal windows side by side (I've really never liked conventional IDEs), but old habits die hard. In my youth I would just dump a handful of small text editor windows on the screen in random locations, one per currently relevant source code file, and nowadays I still have to fight that urge. (Discovering that gnome-terminal supports tabs definitely helped, though.)
One thing that I haven't seen mentioned here is that shorter line limits (80, 120) make my life easier for non-trivial merge conflicts and diffing changes.
I think, it's also depending on the language used.
When I write JS or Python, In getting along with 80 no problem.
But when I do TS or Java, the annotations can stretch lines quite a bit.
When I write JS or Python, In getting along with 80 no problem.
But when I do TS or Java, the annotations can stretch lines quite a bit.
There are certainly tradeoffs, but I find that in general shorter line lengths are better.
- easy to lay out multiple splits side by side. Over 100 tends to have issues.
- long variable names or function names tend to be a code smell. Same thing with too many parameters.
- git works much better at diffing and merging vertical lines than things on one long line.
The main downside is that monitors are wider than tall in general - so fitting more code on the screen is certainly nice! But I find moving my eyes and head up/down to be tiring over the course of the day and tend to use vim to keep things centered for myself anyways. zz, LSP search, go to definition, etc.
- easy to lay out multiple splits side by side. Over 100 tends to have issues.
- long variable names or function names tend to be a code smell. Same thing with too many parameters.
- git works much better at diffing and merging vertical lines than things on one long line.
The main downside is that monitors are wider than tall in general - so fitting more code on the screen is certainly nice! But I find moving my eyes and head up/down to be tiring over the course of the day and tend to use vim to keep things centered for myself anyways. zz, LSP search, go to definition, etc.
> There has been a surprising amount of scientific research around this issue
This article includes a throwaway link to the wikipedia page at the end of that quote. I recommend reading the relevant section (https://en.wikipedia.org/wiki/Line_length#Electronic_text), because it's pretty limited. There is really no way to tell if it (or Glyph) are accurately summarizing the research.
This article includes a throwaway link to the wikipedia page at the end of that quote. I recommend reading the relevant section (https://en.wikipedia.org/wiki/Line_length#Electronic_text), because it's pretty limited. There is really no way to tell if it (or Glyph) are accurately summarizing the research.
I think they meant research around the ideal line lengths for prose which is of course irrelevant.
This is alluded to in the article, but not fleshed out: To me the ideal is to not have any limit on the length of _logical_ lines, but have the editor do syntax-aware _visual_ line wrapping. Then, people can view the code at any column width they want and it just looks right; line numbers don't change just because of reformatting; and most importantly, the programmer doesn't have to waste time thinking about how to break up an expression.
My preference is a normal max of 80, most lines significantly shorter, but if a particular line is more readable if over 80 make an exception.
Code and prose isn't really comparable in this context, because in prose you are meant to read and process entire paragraphs at once, which is why it's important to be able to move from the end of one line to the beginning of the next fast, whereas with code you're meant to process it line by line.
> Even before typewriters, consider the average newspaper: why do we call a regularly-occurring featured article in a newspaper a “column”? Because broadsheet papers were too wide to have only a single column; they would always be broken into multiple! Far more aggressive than 80 characters, columns in newspapers typically have 30 characters per line.
Yes because a newspaper has a frontpage and a fold, and you want to have many headlines on the frontpage above the fold, all with a size matching their importance.
> Even before typewriters, consider the average newspaper: why do we call a regularly-occurring featured article in a newspaper a “column”? Because broadsheet papers were too wide to have only a single column; they would always be broken into multiple! Far more aggressive than 80 characters, columns in newspapers typically have 30 characters per line.
Yes because a newspaper has a frontpage and a fold, and you want to have many headlines on the frontpage above the fold, all with a size matching their importance.
> Similarly, if you really try to use that screen real estate to its fullest for coding, and start editing 200-300 character lines, you’ll quickly notice it starts to feel just a bit weird and confusing. It gets surprisingly easy to lose your place. Rhetorically the “80 characters is just because of dinosaur technology! Use all those ultrawide pixels!” talking point is quite popular, but practically people usually just want a few more characters worth of breathing room, maxing out at 100 characters, far narrower than even the most svelte widescreen.
Well yeah, this seems to be a bit of a straw man. Nobody is suggesting 200 characters. But 80 is definitely anaemic. I think 100 is quite low too, so it seems bold to say "maxing out at 100".
120 is the most comfortable I've found, striking a good balance between readability, excessive wrapping, and side-by-side viewing.
Well yeah, this seems to be a bit of a straw man. Nobody is suggesting 200 characters. But 80 is definitely anaemic. I think 100 is quite low too, so it seems bold to say "maxing out at 100".
120 is the most comfortable I've found, striking a good balance between readability, excessive wrapping, and side-by-side viewing.
I've been writing code (and prose) with 3 vertical rulers for almost 10 years now: 66, 80 and 120 characters each. None of them are hard limits for me. But they do help guide my eye.
Most lines fit under 66. A lot more than 50%, even code written by other people. I'd say most lines also fit under 80, and very rarely do lines actually cross 120.
Most lines fit under 66. A lot more than 50%, even code written by other people. I'd say most lines also fit under 80, and very rarely do lines actually cross 120.
I agree hard limits aren't usually a good idea. Especially because they complicate auto-formatting (the Prettier algorithm which is clearly the best doesn't support them). Also sometimes you want to paste a long URL and that's a pain with hard limits.
I personally find anything over 100 is annoying, 120 is definitely in the more frustrating range for me. I'd much rather a soft limit of < 75 and a hard limit of < 90.
I wonder what it is that makes different people choose different limits.
I wonder what it is that makes different people choose different limits.
Ah, a man of culture, I see. :) I too settled on 120 characters a few years ago and so far I'm still happy with it. Programming is much more verbose than it was 20 years ago, and accordingly, there's plenty to be said for allowing wider lines.
I'm happy with 120.
Wrapping at 88 in java code, where I have method names almost that long, would use too much vertical space and lead to constant scrolling.
This may be an issue with the information density of java code, absolutely, but I don't want ordinary-length functions disappearing off down the screen.
YMMV.
Wrapping at 88 in java code, where I have method names almost that long, would use too much vertical space and lead to constant scrolling.
This may be an issue with the information density of java code, absolutely, but I don't want ordinary-length functions disappearing off down the screen.
YMMV.
It would seem that the optimal solution to both maintain readability and not waste screen space would be to start counting the characters from after the indentation.
Since indentation is stepped, you won't (often) be jumping massive horizontal distances.
I'm with you on the readability (of a single buffer) angle, but how does that "not waste screen space"? It makes it much harder for me to have multiple windows/buffers open side-by-side.
I've been struggling with this lately. My defaults are either 65 (8 1/2 wide paper, 6 1/2 text, leaves an inch either side for notes and hole punch), 72 (usable card image width), or 80 (because terminal were either 80 x 25 or 80 x 43).
My mainframe indoctrination there.
In terms of screen reading width, there's some sweet spot where characters per screen "page" and characters per line are easily readable without the text being "big". I need to be able to move my eyes left to right without losing track of my vertical position on the page.
My mainframe indoctrination there.
In terms of screen reading width, there's some sweet spot where characters per screen "page" and characters per line are easily readable without the text being "big". I need to be able to move my eyes left to right without losing track of my vertical position on the page.
[deleted]
I fall squarely into the 80-column limit camp, at least for C++, but I admit an important exception: string literals used for user-visible messages, like error messages in a compiler. It's important to be able to grep for them reliably and not have to worry about having them be split across source lines.
I’ve use 100 characters, with two columns on a 27” monitor.
Overly short limits butcher semantics, killing a sense of rhythm and continuity. I'm not reading a raw stream of characters, but a sentence-like message intended for humans to understand.
Overly long lines have a similar flaw - they compress too much information, so there's quite literally, no rhyme or reason.
So my approach is to have some sort of honor system: write something that you believe that will be readable to a variety of humans, where similar things are grouped together, and different things are laid out apart.
I do have a limit like 240, but that's more like a guardrail, not an invitation for every line to be that long.
Overly long lines have a similar flaw - they compress too much information, so there's quite literally, no rhyme or reason.
So my approach is to have some sort of honor system: write something that you believe that will be readable to a variety of humans, where similar things are grouped together, and different things are laid out apart.
I do have a limit like 240, but that's more like a guardrail, not an invitation for every line to be that long.
> The problem with this argument is the same as the argument against “but tabs are semantic indentation”, to wit: nope, no it isn’t.
Nit: to whit
EDIT: nit: to wit
Nit: to whit
EDIT: nit: to wit
I googled "to whit vs. to wit" and can't find anything that substantiates this. I think "to wit" is actually correct.
That's right.
https://www.merriam-webster.com/dictionary/to%20wit
https://www.merriam-webster.com/dictionary/to%20wit
Oh my goodness. You're right. I stand corrected.
> Traditional line length research, limited to print-based text, gave a variety of results, but generally for printed text it 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).[1] For conventional books line lengths tend to be 30 times the size of the type, but between 20 and 40 times is considered acceptable (i.e., 30 × 10pt font = 300 pt line).[1]
* https://en.wikipedia.org/wiki/Line_length#Printed_text
There's a section of "electronic text" as well which goes into some factors (flicker, glare), but the number doesn't seem to change that much.
* https://webtypography.net/2.1.2