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

211–220 of 330 posts

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

#211

Post by fauigerzigerk »

taeric wrote: post #162
l0b0 wrote: post #134

Earlier quoted context omitted.

Another reason the assumption that style rules for natural language is transferrable to code is kinda baffling. I wonder if there's ever been much research in this space which doesn't make that assumption.

It is more than just natural language. You could look at math journals, for their jargon. Music notation. Recipes. Really, is there any writing that doesn't seem to apply?

It doesn't apply to code to the same extent, because reading code rarely means reading every single line left to right.

Also, lines ending on column 100 are not necessarily 100 characters long. There could be indentation on that line and on the next.

Vertical alignment has meaning in code whereas it ususally doesn't have meaning in natural language text.

So if you insert line breaks into code purely to follow some arbitrary rule, you are misleading readers into looking for meaning where there is none.

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

#212

Post by bjoli »

voodootrucker wrote: post #139
williamdclt wrote: post #127

Earlier quoted context omitted.

And his email client hard-wraps at 80 chars, because that's the standard of both Linux and Git mailing lists, because they send patches in emails. I like the irony :)

> patches in emails Cringe.

Give me a better non-locked-in experience than a mailing list, gnus/mu4e and magit and I am happy to try it out.

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

#213

Post by bscphil »

klingonopera wrote: post #142
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

> "the average font size has been steadily creeping, maybe 1.5 pts per 5 years." To be fair, so has the monitor resolution and its density. I'm looking at HN, and imagine, ten years ago, I was using 1280x1024 then, this very font would've physically been a much bigger picture. So in effect, the font-size increase may only counter-measuring the resolution increase...

> the monitor resolution and its density

On most operating systems, this is supposed to be almost irrelevant since they use a "virtual" resolution and DPI that gets used to render apps at a reasonable size across displays.

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

#214

Post by zapzupnz »

hinkley wrote: post #172
ryandrake wrote: post #166

Earlier quoted context omitted.

The problem with this idea is you then get these web site designers who take it as dogma and try to force a particular width, without regard for the browser window size. This results in sometimes 1/2 or more of the horizontal area on the page wasted by this giant white space border. If you must have a margin, at least make it a reasonable percentage of the browser window width. Or better yet, don’t force my browser t…

Somewhere I have a picture of daringfireball taking up around a quarter of the monitor width and just blank space around it.

The stylistic choice there may be informed by macOS' window manager defaulting the window size to "just big enough to fit the content".

It's only really since full-screen windows came to play that the issue with Daring Fireball really become obvious; prior to that, macOS users rarely made their windows fill the screen in the same way that Windows users are prone to do.

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

#215

Post by zapzupnz »

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…

> This misses the point, same as Linus (which i honestly find surprising)... 80 width lines is a target to try to achieve _naturally_,

The post is about changing code style formatting rules for code that goes into the Linux kernel. Not guidelines, rules. The tools in question, I presume to be a linter or formatter, complained noisily about line length prior to the adoption of this change.

It's not about someone misinterpreting guides as absolutes. It's very much about absolutes, in this case, that serve as guides.

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

#216

Post by rbanffy »

enriquto wrote: post #207
fouric wrote: post #175

Earlier quoted context omitted.

This. The problem itself has nothing to do with the number of characters you have on a line - the problem is that the vast majority of programming tools today conflate content and presentation. The job of making sure the line length is reasonable is not up to the writer of the code - it is up to the tools that are used to read it. Lines should be as long as necessary, and then intelligently (i.e. syntactically-aware)…

> the problem is that the vast majority of programming tools today conflate content and presentation. This is not a problem, but a beautiful and crucial property of text files. I like the principle that "a program is a text file", that you can edit with tools orthogonal to the language in question

With that in mind, you are free to reformat the file to your tastes on checkout and do it with repo-compliant standards on commit.

If I did work for Google, with their heinous 2-space tabs, I'd certainly do that all the time.

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

#218

Post by rbanffy »

bsder wrote: post #119
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.

If you nest code that deep, you probably should extract some logic into separate functions.

I remember Linus saying that explicitly.

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

#219

Post by jabirali »

demosito666 wrote: post #205
TeMPOraL wrote: post #111

Earlier quoted context omitted.

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

The more reasons to use narrower lines, right? I mean, I work in two files side by side 50% of the time, and with 120 chars the text would require wrapping, which is really unreadable in e.g. python.

Personally, I prefer handling long lines via horizontal scrolling (with keyboard shortcuts) rather than wrapping.

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

#220

Post by zapzupnz »

bjoli wrote: post #206
aimor wrote: post #196

I'd rather have 80 columns on a 4:3 ratio than 120 columns on 16:9. "A wide monitor is for" watching video, playing games, and putting larger diagonal numbers on the box. I miss turning one monitor sideways to nearly fit an A-sized document. And I miss those 120 extra vertical pixels from before 1080 became the standard. I think the only good and common option right now is 21:9 in a large size and resolution, you sti…

I would gladly pay twice the price for a 4k 4:3 or 3:2 monitor. Even on wide displays, I rarely split top-to-bottom more than once. More vertical space would mean a lot more usable screen estate for me.

So just turn a 16:(9/10) monitor sideways. Plenty of vertical space.
Post reply on HN