80 characters is nice for side by side buffers. Also, lines that are too long horizontally are difficult to scan (especially if they are much longer than the lines around them) and can benefit from some work on vertical layout.

How much time do developers spend on side by side buffers?

I get the difficult to scan point (although I find it subjective) but the side-by-side argument is optimizing for a comparatively small use case.

    > How much time do developers spend on side by side buffers?

In my case: all the time. On my desktop (which has a large display) I often tend to have 3-4 vertical buffers open. Being able to fit all my code in those buffers is a godsend.

I know this is a bit of a rare condition, but I have very sensitive eyes, so I need to work on a single small laptop screen with decently large font size, otherwise I get eyestrain and I'm out for a week. So when I have two emacs windows open even 80 characters wraps around. I put up with it, but when a codebase has something like 70 or less characters per line I find it much easier to develop in.

It's my default. On the left buffer I've got the implementation, on the right buffer I've got the spec/test.

It's my default mode of working. Even in a statically-typed language (I mostly write Haskell these days), I often have one buffer for the things I'm working on, and 1..N buffers of references or parallel changes.

> Case and point, 80 character line limit: this was a reasonable limit when command lines were not usually rendered inside of high-res framebuffers, I have my font set to 12 point M+ font, which is a narrow width font, so my terminals are set to open at 180 characters wide and it only takes up half the width of my screen.

Use three terminals? No, seriously, you can pack even more information into the screen than you already do, which was already presumably your intent when you switched to the font. Wouldn't that be the logical end-limit here? After all, most tools still standardize around 80 characters, most terminals on GUI machines start up for the first time with 24 rows and 80 columns. It seems like you're arguing against an unnecessary standard.

Hell, wouldn't the proper solution here be to add a flag or a config file to the analyzer to alter the defaults, rather than. This is already a solved problem for code analyzers in general, most C linters (including clint) support these flags.

I'm actually not arguing to change the default, I'm arguing that the team should have a conversation and decide on whether the default is reasonable for them. I'm not using a narrow width font because I want to pack more information on the screen, in fact I'm using it because it's more readable, at any size (small or large.)

I actually hope that when I have this conversation with my team, someone looks at my screen and says "hey, that is a nice font, and more readable than what I've been using."

> After all, most tools still standardize around 80 characters

I use standard Linux tools for development, and none of the tools themselves have any column standard. Probably text-only emails are the only thing that have a "standard" of 80 columns.

> most terminals on GUI machines start up for the first time with 24 rows and 80 columns

This doesn't really mean anything. I don't think there's anybody who leaves the terminal as it is, as even on a modest 1080, that'd be one quarter of the screen area.

I get your point, but i think the main reason for using 80 character line length nowadays is that its more readable. Books use often line lenght of about 60 characters for this reason.

That's fine, when it is more readable... but there is a convention in Ruby of making your classes and method names as descriptively as possible, not even ruling out the possibility that they might be very nearly full sentences.

I am in strong agreement that there should be a character limit, and I'm even convinced that my 180 character wide terminal is longer than what would be an appropriate limit. But 80 characters is less than half of that, and so I'm not convinced that honoring a default 80 character limit is going to make anything more readable, more likely that it will just result in me turning up my font size so there is not so much unused space on my screen.

I think it's also true that most people use a larger than 80 character wide terminal today.

I guess the point is, without getting hung up on this knob in particular, that fewer knobs is pretty much always better; at least that was the central theme of the issue where I got the idea that Rufo maintainer team has this outlook: https://github.com/ruby-formatter/rufo/issues/2

On that knob -- I prefer 80 characters today because it allows me to place two panes of code side-by-side without wrapping on one monitor. Sometimes I throw in a REPL pane as well as or instead of the second pane.

But I also have come to like prettier's approach. At least, I did last time I used it a year or two back. Almost no configuration, no bikeshedding, it just reformats your js code and doesn't sweat the rest. It's not having every style exactly how I like it, but it's much nicer than the eslint/jshint/etc hell I used to configure. Of course to some extent these tools solve some different problems but I didn't really feel much of a need to keep eslint around once prettier started enforcing its standards.

Definitely check out prettier for Ruby then! https://github.com/prettier/plugin-ruby. Actively working toward 1.0.

This! I prefer 80 characters so I can have two panes of code side by side or a REPL next to my code. It is near impossible to do that on a laptop if the line length is extended to 110 without a line wrap.

Point being, everyone has very different preferences and work practices. Team standards are going to be very different from team to team but standards do help reduce cognitive overhead on wondering if line lengths or other styles need to be different.

80 character is better for us old coders who need a larger font size but still want to see two files side by side on a small laptop screen without side scrolling.

I'd love to accommodate you, but I'm still struggling to get my team of 8 to agree that we should impose any line length limit. My terminal is 180 characters wide because I have some team members that don't seem to believe in line breaks as a force of habit.

You don't even know how long these 100 line functions really are! It's abusive, bottom line.

80 characters is best for those of us with disabilities who still rely on limited real estate screens.