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 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.

> 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

0.618 * screen width

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]

* 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

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

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 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.

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.

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’ve use 100 characters, with two columns on a 27” monitor.

> 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.

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.

> 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.