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

61–70 of 330 posts

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

#61

Post by qchris »

catalogia wrote: post #8
TazeTSchnitzel wrote: post #3

I spend a lot of time writing code on my laptop, and while that could display two 100-column terminals side-by-side, I prefer to also be able to see other windows on my screen while having text at a size that doesn't strain my eyes.

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.

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

#62

Post by alkonaut »

Or just accept that a few lines in a code file or log is longer than the screen.

Don’t use wrapping, it destroys the layout (of a log etc).

Just scroll to see the rest of the line! You scroll down to see any lines that aren’t on screen, why would (occasionally) scrolling right be worse? Readability is some times worse with wrapping.

If you want to answer “but my terminal can only trim or wrap, not scroll!” then perhaps that’s a relic just like the 80 wide display?

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

#63

Post by dboreham »

okareaman wrote: post #22
shockinglytrue wrote: post #13

Typical ill-considered comment from Linus, and surprising for someone getting on his years. Column width is an accessibility issue . I'm barely in my mid 30s and the average font size has been steadily creeping, maybe 1.5 pts per 5 years. I could tolerate 132 column files today, but by the time I'm 50 there is no way this will work, regardless of screen size

I'm 62 and don't normally wear glasses, but reading glasses have become a big part of my life. I use 1.0 to look at my big screen, 1.75 to look at my phone and always misplace them somewhere.

Head to Costco and buy three three packs of the diopter strength you loose. It'll take a few years to loose 9 pairs and if you bust them out of the pack when a pair is lost then you always have a scratch free pair.

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

#64

Post by vlovich123 »

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.

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

#65

Post by nicoburns »

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…

Shirt lines have the problem that they make it much more difficult to scan the whole document for someyhing because they increase vertical distance. You can fit less on the screen at once.

I actually prefer long lines even if I have a small screen and need to horizonally scroll. Often the content at the end of the line isn't even that important.

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

#66

Post by ceocoder »

Here is Rob Pike on 80 column limit[0], I’ve seen folks having to go through just crude gymnastics to make 80 column check for pep8/flake8 before someone inevitable disabling that chek/or add ignore check for that line. One think I love about gofmt is it does not give a rats behind for how long a line should be.

[0] https://twitter.com/rob_pike/status/563801489190043648?s=21

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

#67

Post by robbrown451 »

I'm all for soft-wrapping. I sometimes cram windows side by side so I can see more files at once, and sometimes spread them out so I can see more of a file at once. I move and resize windows as the need arises.

And I really don't want to spend brain power thinking about where to wrap things. I was glad that word processors made it so I didn't have to think about carriage returns after about 1981 (yes I learned to type on a mechanical typewriter), and glad I stopped having to think about it in source code around 2010.

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

#68

Post by TheDong »

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…

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 line-oriented (same for sed, etc). Sure, it's possible to make the output have context, but to actually do a multi-line grep correctly is much more complex.

I think that's the sort of grep usage linus was referring to.

> So I dunno, still prefer 80-88 characters for coding, 100 max.

I also prefer most lines to be under 80 characters, but for the sake of keeping a function call on one line, or keeping important things together, I'm fine with exceptions.

Some code splits onto multiple lines naturally (like moving a function call in a function's arguments into its own temporary variable). Other times, it becomes less readable as several shorter lines.

Thus I don't think a hard rule of 80 is good, simply a general philosophy that readable code is good and that's more important than line length.

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

#70

Post by andai »

JoshTriplett wrote: post #29
winrid wrote: post #19

Earlier quoted context omitted.

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 use keyboard shortcuts for that: Win+left and Win+right will maximize a window on that half of the screen. That makes it easy to quickly have a terminal or editor on one half and something else (like a browser or PDF) on the other half, using only the keyboard.

To clarify, these are built in (everyone running Windows has them).
Post reply on HN