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

281–290 of 330 posts

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

#281

Post by tomxor »

zapzupnz wrote: post #215
tomxor wrote: post #94

Earlier quoted context omitted.

> 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 misin…

> The post is about changing code style formatting rules for code that goes into the Linux kernel. Not guidelines, rules.

Then it is about absolutes, the rule is absolute, but 80 width is a guide... being used as a rule.

I'm surprised the first to challenge the rule is about grepability and not how detrimental it is to legibility to use this as a hard rule.

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

#282

Post by u801e »

ogre_codes wrote: post #274
JoeAltmaier wrote: post #230

Earlier quoted context omitted.

Tell that to 'functional programming' people, or the lambda-crazy people who put entire functions in argument lists to the point you can't parse a statement to save your soul. I've had to print and highlight code to figure out where it began and ended.

> ...who put entire functions in argument lists to the point you can't parse a statement to save your soul. As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code.

> As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code.

Isn't perceived difficulty of reading code correlated with how familiar one is with the language it's written in? For example, code may be harder to read for someone who lacks experience or is new to the language, but it's not difficult for someone who is experienced and is familiar with the language.

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

#283

Post by wool_gather »

moonchild wrote: post #263
wool_gather wrote: post #256

Earlier quoted context omitted.

Turning the entire file into a single line really doesn't seem like a solution. Now foo(1, bar, false) print("Hello, world") flag = true shows up in your grep output, and not in a particularly helpful rendering.

No? That just merges continuation lines. So if your original file is foo(1, \ bar, \ false) print("Hello, world") flag = \ true Then the postprocessed output is: foo(1, bar, false) print("Hello, world") flag = true And your grep output is just foo(1, bar, false)

Sorry, what language are we talking about that has escaped line continuations for expressions like that?

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

#284

Post by burntsushi »

bcrosby95 wrote: post #238
burntsushi wrote: post #146

Earlier quoted context omitted.

I have a certain monitor width, distance from that monitor and font size. Those constraints dictate how many open file columns I can fit across my screen. I'm happy if I can get two columns, so that I can edit files side-by-side. 80 columns is the approximate sweet spot. The suggestion that people should just get "better hardware" is so completely asinine, because it neglects to realize that the quality of hardware m…

He never said to buy better hardware. He said the code should no longer be formatted based upon what he believes to be a niche situation. People in this situation can, in fact, still edit code. You will get line wrapping. It's not optimal, but neither is editing 80 lines when you have 100 available.

You missed my point. My point here is that reasonable people can disagree if you just take a second and think about others' perspectives, workflows and development setups. But no, Linus is literally arguing that reasonable people cannot disagree because he's arguing that an 80-column limit isn't "reasonable." That's a bunch of bullshit.

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

#285

Post by shultays »

naikrovek wrote: post #275
ogre_codes wrote: post #126

Earlier quoted context omitted.

> 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. There is some truth to this, but it's largely irrelevant. When text is laid out for books, it's based on a fixed width and each sentence follows the next. Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line wid…

> Good programmers gravitate towards shorter lines of code by nature. If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems which need to be addressed. This kind of thing is really obtuse and it drives me insane that so many people subscribe to ideas like these. This kind of thinking is what leads to linters with completely arbitrary rules telling me h…

When is shadowing is right thing to do? Why picking a new variable name wouldnt work?

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

#286

Post by zapzupnz »

charrondev wrote: post #255
zapzupnz wrote: post #214

Earlier quoted context omitted.

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.

> that Windows users are prone to do. Or how iOS users tend to do.

Indeed. I was thinking about iPads, but I didn't mention it because the design predates iOS — but yes, it's absolutely true.

And he hasn't optimised the design for iPhone-sized devices much but I think that's deliberate.

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

#287

Post by Avamander »

Hot take, the same applies to Git.

Description should be autowrapped to each individual's preference, some have larger screens, some smaller, some need larger fonts, some smaller. The message shouldn't have a pedantic upper limit either. Fscking autowrap it if you're using a VT-100.

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

#288

Post by dragonwriter »

ogre_codes wrote: post #126
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…

> 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. There is some truth to this, but it's largely irrelevant. When text is laid out for books, it's based on a fixed width and each sentence follows the next. Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line wid…

> Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line width.

No, it doesn't, especially for code that isn't written in a very basic simplistic imperative style. Expressions have no natural size limits (and statements, in languages that even have them, can generally each contain one or more expressions.)

Languages tend to develop conventional line width limits and conventions for where to prefer to break within expressions to achieve them, but there is no natural length limit to the length of a single statement.

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

#289

Post by Avamander »

u801e wrote: post #272
williamdclt wrote: post #240

Earlier quoted context omitted.

Your argument stands, but this non-locked-in experience is so bad it locks most people out. I've done it, I did contribute to Git, and the experience was horrible. The amount of time spent on the mailing part was far far greater and confusing than the amount of time writing code (one of the patch was just a wording change actually). And I don't see how using github locks you in, switching to gitlab, bitbucket or what…

> so bad it locks most people out. Could you specifically describe why it locks most people out? > I did contribute to Git, and the experience was horrible. What was bad about it? > The amount of time spent on the mailing part was far far greater and confusing than the amount of time writing code From what I've read on the mailing list, a lot of the time was spent discussing the patch or patch series in general. That…

The single conclusive answer to your questions is "everything", absolutely every single component in that process is obsolete, cumbersome, finicky and convoluted. What's confusing about that description?

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

#290

Post by dkersten »

I went from kinda following the 80 character “rule” to 120, to not following it at all and now back to 80. Why? Because I like to have three editor windows side by side and at the font size I’m using, going above 80 means I have to scroll and word-wrap looks unpleasant to me.

Keeping lines short also helps when pasting code to instant messengers or reading side-by-side git diffs.

Post reply on HN