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

271–280 of 330 posts

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

#271

Post by ogre_codes »

ThrowawayR2 wrote: post #239
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. " I can't agree with that. When you've got class names like AbstractSingletonProxyFactoryBean and similar naming conventions for variables, 80 characters just isn't adequate a lot of the time.

Just skimming our codebase, 20+ character variable names are fairly common. Even with verbose variable names, the majority of our lines of code are less than 80 characters. Probably 1 our of every 15-20 lines of code stretches longer and we greatly appreciate that we can go longer, but the majority are shorter.

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

#272

Post by u801e »

williamdclt wrote: post #240
bjoli wrote: post #212

Earlier quoted context omitted.

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

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's what should be done when submitting changes.

What was confusing about it?

> And I don't see how using github locks you in, switching to gitlab, bitbucket or whatever is dead simple.

Well, with issues, metadata in PR discussoins, etc, migrating does take a bit of effort. What's simple about it? On the other hand, I could connect via NNTP to public inbox (or possibly gmane) and download 15+ years of patch series discussions in a couple of minutes.

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

#273

Post by ogre_codes »

rmrfstar wrote: post #229
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…

> If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems In math-heavy stuff, lines tend to be longer. You are usually trying to convert one line of math into one line of code. I myself shoot for 160 character columns. See, e.g. [1]. [1] https://docs.fast.ai/dev/style.html

I agree, math is a perfect example where code is more clear to have a single long statement on one line. I am a bit skeptical that you have a big codebase with math on more than a quarter of the lines of code though. Most likely there are a lot of shorter lines between your formulas which is exactly my point here.

When long lines improve readability/ clarity you should have the ability to use them.

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

#274

Post by ogre_codes »

JoeAltmaier wrote: post #230
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…

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.

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

#275

Post by naikrovek »

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…

> 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 how I should solve my own problem.

Me: "Hey linter, I'm going to shadow a variable name here, because that's the right thing to do in this situation, so shut up about it."

Linter, and 5 billion HN commenters: "you're shadowing a variable. Compile warning."

Me: "it's a language feature, and it's ok to use."

Linter: "you're shadowing a variable. Compile warning."

Etc.

Arbitrary rules like line width (and I assure you, those rules ARE arbitrary) help exactly 0 people per day, and cause problems for more than 0 people per day.

I PROMISE that a human brain is better at discovering general code quality problems than the best linter with the best rules, and that will be true until a time when every reasonable computer is a general purpose AI.

Yes, tell me when I have a memory leak. Use static analysis to tell me about weird issues I have difficulty seeing. I know best about line width and how to solve things in my own application better than any linter could ever hope to, because linters do not have anything approximating the intelligence of gnat, nevermind a human being.

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

#276

Post by [deleted] »

sesuximo wrote: post #249
bryanrasmussen wrote: post #181

Earlier quoted context omitted.

When I hear the word intelligently used in the context of something a computer should do I start to think that perhaps the reason it doesn't do it yet because our expectations are too wide and fickle for it to work as yet. So perhaps this is the test of AI, when it formats my code the way I want it all the time without making a mistake.

I think it’s pretty simple. Word wrap the way a N-character wide linter would

[deleted]

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

#277

Post by 0-_-0 »

sesuximo wrote: post #249
bryanrasmussen wrote: post #181

Earlier quoted context omitted.

When I hear the word intelligently used in the context of something a computer should do I start to think that perhaps the reason it doesn't do it yet because our expectations are too wide and fickle for it to work as yet. So perhaps this is the test of AI, when it formats my code the way I want it all the time without making a mistake.

I think it’s pretty simple. Word wrap the way a N-character wide linter would

Yes! Someone please make this a reality!!

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

#278

Post by labawi »

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…

> Arbitrary rules like line width help exactly 0 people per day

I use a linter, it warns about long lines (adjusted to 100), so I reformat or split them and the code seems more readable. Also, it has consistent formatting (other rules), though I occasionally mark some lines to be ignored.

I'd say it helps me, which is >0 people. You don't have to follow norms and/or best practices, but some find it useful.

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

#279

Post by ric2b »

PunksATawnyFill wrote: post #253
wolrah wrote: post #234

Earlier quoted context omitted.

100% the reason I'm a tab guy. If I'm glancing at some code on my phone, I can have it set to two space tabs to maximize the amount that fits on screen. If I'm on my desktop they're four spaces because my screen is huge and more visibly apparent indentation is valuable. Same editor, same data. If it's a shared codebase and someone else likes 8 space tabs, 6 space, or whatever they want (13 space? no kinkshaming here.…

Yep. I have yet to hear a coherent argument against tabs. It’s such a tiresome squabble.

Vertical alignment of related lines.

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

#280

Post by ric2b »

0-_-0 wrote: post #203
jml7c5 wrote: post #199

Earlier quoted context omitted.

Not really a solved problem. Even if you set your editor to display 1 tab as 2 columns, another person may set their editor to display 1 tab as >2 columns. So even using tabs, a project has to set rules for tab width.

Why would that be a problem? That's the point, that you can set tab width any way you want.

The argument is that the line length limit has to be related to some default indentation length, which in Linux's case is 8 spaces.
Post reply on HN