Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

But no, 80-column terminals in 2020 isn't “reasonable” any more

lkml.org

Post reply on HN
Print view View original

111–120 of 330 posts

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#111

Post by TeMPOraL »

avodonosov wrote: post #96

Optimal code line width has very little to do with monitor or window width. It's more of an anatomical restriction: the resolution of the human eye and the field of view. For example, if we had 10 meter-wide monitors we won't be able to see them entirely from a close distance. Increasing the distance will require to increase the font, so the number of characters per line we can use doesn't change much. Not so long ag…

Details matter.

The way I'm set up at my desktop, my editor can fit ~320 columns. Which means I can fit four 80-column-wide files side by side. Three, if you account for line numbers on the margin.

(I usually do two, because my code tends to go up to ~120 characters.)

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#112

Post by chipotle_coyote »

vlovich123 wrote: post #64
js2 wrote: post #49

The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 c…

Is there any research to suggest that reading legibility of code is the same as for regular text? Unlike regular text code often has special characters & indentation to break it up, so intuitively I would assume it could support longer line lengths.

I was wondering the same thing, yes. I'm often an annoying stickler about keeping line length for text on the web set to what a couple centuries of book design have taught us makes long-form prose more readable, but code is not prose. I try to keep multi-line comments wrapped to around 78 characters, but I'm not really too worried about code.

(This invites a rant about people, usually people who use Emacs, who put hard line breaks in text paragraphs, but I'll save it for another time.)

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#113

Post by ncmncm »

qchris wrote: post #61
catalogia wrote: post #8

Earlier quoted context omitted.

Even on very large high resolution screens, it's nice being able to tile that many more files on the screen. I think 'narrow' source code is advantageous no matter your display.

I agree with you to a degree, but one of my pet peeves about certain linters and code formatting tools is when they take something that could easily be a very understandable single line, and break it up into three or more lines because that's what the normal rules look like. As a result, sometimes a 15-20 line function ends up being over 50 lines, and I end up not being able to see the entire thing without scrolling.

Yes, lining up arguments in a deeply indented column is criminally wasteful. Whitespace is a limited resource, to be applied where it is useful. Splattering it everywhere leaves nothing to use to unobtrusively direct attention where needed.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#114

Post by jacobsenscott »

If there so some tool everyone uses that constraints the width use that. Otherwise treat programmers like grown-ups and let them break their lines where they want.

The width of a github code window is about 120 characters. That's suggested max line width because horizontally scrolling diffs during a code review is terrible. It is rare that we have any lines close to that long though.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#115

Post by [deleted] »

tomxor wrote: post #94
TheDong wrote: post #68

Earlier quoted context omitted.

Let's say I want to find every function call too `foo` that passes `true` as the last argument. I might do something like `grep "foo\(.*true\);"` That would work well enough if the codebase was mostly uniform and all calls to foo were on a single line. However, if we have callsites like "foo(x->y(get_arg(z)), something, \ntrue);" where 'true' is split onto a newline, that naive grep misses it. As linus says, grep is…

> where 'true' is split onto a newline, that naive grep misses it. This misses the point, same as Linus (which i honestly find surprising)... 80 width lines is a target to try to achieve _naturally_, if someone is splitting code by inserting unnatural breaks then they are trying too hard, OR there could be various other legitimate reasons like very long function names and naturally verbose PL syntax that make even lo…

[deleted]

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#117

Post by jacobsenscott »

Fiahil wrote: post #39

I guess most of us, pragmatic people, agree that 80 columns is not a sane standard anymore. The more interesting question is "what would be a good default line length in 2020?" I vote for 120 columns.

Github is the new fixed width terminal, and 120 columns is about right for that. That's our standard.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#118

Post by threatofrain »

avodonosov wrote: post #96

Optimal code line width has very little to do with monitor or window width. It's more of an anatomical restriction: the resolution of the human eye and the field of view. For example, if we had 10 meter-wide monitors we won't be able to see them entirely from a close distance. Increasing the distance will require to increase the font, so the number of characters per line we can use doesn't change much. Not so long ag…

You don't read code the way you read a book or long-form document, as authors generally don't optimize for vertical reading.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#119

Post by bsder »

avodonosov wrote: post #96

Optimal code line width has very little to do with monitor or window width. It's more of an anatomical restriction: the resolution of the human eye and the field of view. For example, if we had 10 meter-wide monitors we won't be able to see them entirely from a close distance. Increasing the distance will require to increase the font, so the number of characters per line we can use doesn't change much. Not so long ag…

I would be more sympathetic to 80 column limits if Linux didn't have indent set to 8 columns.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#120

Post by chipotle_coyote »

winrid wrote: post #19
krferriter wrote: post #9

Earlier quoted context omitted.

I think a lot of terminals just set that as the default window width. No real reason for it, I usually snap to half the screen width immediately anyways. That turns out to about 105-120 characters width. Some people might just not resize it most of the time. Especially on Mac where efficient window management just isn't a thing.

A note on your last sentence. Once I used my Win10 laptop at an interview at Apple. The interviewer saw me drag one window the the side, snap it, and then select another window to fill in the space. He said, wow, Windows is really nice! :)

I've gotten used to doing that not with the mouse but keyboard shortcuts, using an, um, let's call it venerable third-party Mac program called Moom. Moom has a drag-to-snap feature similar to Windows' functionality, but whenever I enable it, I find myself constantly resizing windows by accident. This is funny to me only in that it seems really ironic that as a long-time Mac user who's been known to argue with the "only use the keyboard" crew over the relative virtues of pointing devices, this is something I do way better with the keyboard.
Post reply on HN