TeX has a default of 66 characters per line. There's been research on this:
> 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]
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.
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.)
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.
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?
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.
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.
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.
> 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.
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.
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.
> 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 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.
Readit News
> 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
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).
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.
I wonder if technical density affects optimal line length.
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?
"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.
[0]: https://journal.stuffwithstuff.com/2015/09/08/the-hardest-pr...
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.
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
> 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.
And that's before we factor in all the nonsense IDEs like to clutter the screen with.
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.
- 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.
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.