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

251–260 of 330 posts

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

#251

Post by im3w1l-alt »

deepspace wrote: post #246
ThrowawayR2 wrote: post #239

Earlier quoted context omitted.

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

To be fair though, if you have class names like AbstractSingletonProxyFactoryBean, then terminal width is the LEAST of your problems.

You may be in a position where using a verbose framework or libraries save you way more effort than the small pain they bring.

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

#252

Post by dragonwriter »

978e4721a wrote: post #248

Jesus, what a bullshit. It's not about screen size, it's about reading experience. If you think that longer lines making something easier to read - try to read non-trivial book with 100 characters width.

Books tend to use proportional fonts which can tolerate greater average line lengths (measured in in characters) than monospaced fonts of similar size (same em), and in any case won't have a constant length in characters line-to-line, but instead vary based on the specific test to be similar in total width.

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

#253

Post by PunksATawnyFill »

wolrah wrote: post #234
justaguy88 wrote: post #173

Earlier quoted context omitted.

Ah so you're "tabs" haha

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.

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

#254

Post by PunksATawnyFill »

jml7c5 wrote: post #199
ASalazarMX wrote: post #143

Earlier quoted context omitted.

This was a solved problem with tab indenting. It's a bit unfortunate that space indenting won, but I understand why.

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.

This is always the argument against tabs, but it makes no sense. So what?

If you don’t like your tab width, CHANGE IT. That’s a huge win over spaces, where indentation is hard-coded.

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

#255

Post by charrondev »

zapzupnz wrote: post #214
hinkley wrote: post #172

Earlier quoted context omitted.

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.

> that Windows users are prone to do.

Or how iOS users tend to do.

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

#256

Post by wool_gather »

moonchild wrote: post #178
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…

Then pipe through perl -pe 's/\\\n//g' Before grepping

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.

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

#257

Post by karmakaze »

Google "common|popular|standard source max line length"

125 characters per line is the real de facto coding standard for maximum line length these days, because this is the maximum number of characters that you can see in the GitHub diff view. This used to be 119 characters, but the page layout changed.

I just updated my editor to show rulers at 100, 120, 125.

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

#258

Post by fauigerzigerk »

taeric wrote: post #236
fauigerzigerk wrote: post #211

Earlier quoted context omitted.

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

Same is true for most all reading. Skim then read, is a predominant form is reading. Is why newspapers scatter their stories throughout. Indeed, they punish linear reading... Recipes often do two columns of some things. Math jargon is all about repetition. Narrative, explanation, exposition. Don't get me wrong, I am inclined to agree with you. But we don't have a ton of empirical evidence on our side.

>But we don't have a ton of empirical evidence on our side

Neither does the other side, unless you accept the premise that reading natural language text is similar enough to reading heavily indented code where that indentation has meaning. I don't accept that at all.

The studies that were done on natural language text assume that line length is equal to the column where the line ends (i.e all lines begin on the left edge). That's not usually the case for indented code.

If reading long lines takes more effort because your eyes have to travel further to find the next line, then the amount of indentation the next line has matters are great deal.

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

#259

Post by grok22 »

Terretta wrote: post #161
DoubleGlazing wrote: post #124

I think this is a subject most editors fail to address. A single line of code should be written to file as a single line - no matter how long. However, the editor you are using should be able to gracefully word wrap it depending on your settings. Most editors word wrap based on window size or some other hard setting. They should be able to wrap gracefully at a logical point in the code e.g. at a comparison operator o…

> wrap gracefully at logical point in the code This is so clearly right, how can it not yet exist? ‘Just’ dynamic virtual pretty print per personal lang style prefs.

http://journal.stuffwithstuff.com/2015/09/08/the-hardest-pro... might explain why 'just' doing the pretty print on the fly might not be a easy thing (even if the problem here is limited to a single line of code and something based on line length).

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

#260

Post by ASalazarMX »

catern wrote: post #170
ASalazarMX wrote: post #143

Earlier quoted context omitted.

This was a solved problem with tab indenting. It's a bit unfortunate that space indenting won, but I understand why.

What do you mean? Linux uses tabs.

Winning doesn't mean completely extinguishing the competition.
Post reply on HN