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

    \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

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.

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

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.

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.

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.

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.