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

181–190 of 330 posts

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

#181

Post by bryanrasmussen »

smabie wrote: post #167
falcolas wrote: post #148

Earlier quoted context omitted.

Even vim handles word wrapping well. A text editor which can't... well, it's a pretty poor text editor then, isn't it? That said, I don't know of many text editors (outside of notepad, and even that's gotten better lately) which don't offer options about how to (or not to) wrap text.

No text editor that I know of intelligently word wraps code. Vim doesn't and Emacs doesn't either.

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.

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

#182

Post by _ZeD_ »

saagarjha wrote: post #84
joshuamorton wrote: post #82

Earlier quoted context omitted.

Well the real answer is that we shouldn't treat code as "line oriented". It's a tree. Use a tool meant for tree processing, like clang-format or the various similar tools for other languages. These let you query the AST or CST of the language, which is very useful. Often you combine this with a line oriented but overly false-positive prone query, like a file-level grep for `foo`, since the AST parsing is slower. Then…

Unfortunately, this now means that your code searching tool must have knowledge of the language you are running it on. Generally, since you want one tool, that means it needs to either support them all or be designed like LSP…

Or... You can use and ide for this... (Eclipse have generic text and specific programming search for that)

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

#183

Post by _ZeD_ »

RHSeeger wrote: post #171
juanbyrge wrote: post #4

I remember bikeshedding with my coworkers about this topic a few years back while coming up with lint settings. We ended up analyzing all current line widths and realized that something like 98% of lines were under 110 characters, so that is what we ended up using.

But the thing to remember is that you don't need to have a rule of "lines must be no longer than this". Instead, it should be "aim for lines no longer than this", and then sometimes, you need longer because it makes sense in that specific case.

How can you make a linter for this?

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

#184

Post by ak217 »

Can we please just settle on 120 columns as the new 80? It would make things so much more reasonable.

I have to agree going wider than 120 makes things harder to read. 80, no, there is no way I'm going to voluntarily follow that standard - I will have to be forced into it, and I won't like it.

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

#185

Post by travisjungroth »

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.

One thing that's a little tricky is once you do that, the real code doesn't match what's on the screen. Not so bad if it's just whitespace, a little worse if you have to add characters to allow the line breaks. Still, I'd like it and would probably use it. I'm sort of a sadist in that I like 120 width, even though I can't quite go 2 windows wide on my laptop. I just side scroll like a peasant.

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

#186

Post by alanbernstein »

_ZeD_ wrote: post #183
RHSeeger wrote: post #171

Earlier quoted context omitted.

But the thing to remember is that you don't need to have a rule of "lines must be no longer than this". Instead, it should be "aim for lines no longer than this", and then sometimes, you need longer because it makes sense in that specific case.

How can you make a linter for this?

Use warnings for long lines instead of errors?

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

#187

Post by _ZeD_ »

_jal wrote: post #73
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 actually really hate that behavior. I arrange windows to provide the information I need. That's usually a strip on the left to show the mailbox pane of my mail window, a strip below that for slack channels, and a finder window on a scratch directory. To the right are my work windows. Window snapping makes that impossible, about the only thing you can do is pretend you're using a tiling WM and cmd-tab any time you n…

https://pureinfotech.com/how-resize-two-snapped-windows-at-t...

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

#188

Post by hinkley »

If you’re going to have this argument, it’s important that you do it right.

The question is not precisely “how wide can I display code”. The question is “how wide is a side by side diff?” That is the worst case scenario for code reading, and it is the one where the worst classes of errors can slip in (one where neither author actually wrote the bug).

Linus answers this indirectly: you can easily diff 100 characters on a monitor smaller than his. What he says instead sounds like an invitation to suggest 200 column source code, which most definitely is a problem to diff.

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

#189

Post by squaresmile »

williamdclt wrote: post #136

I see a lot of people saying that 80 char is a thing of the past, but that's not really my experience: My work machine is a macbook pro 13", I rarely have a second monitor (and when I do, I tend to have my browser on it). I get 2 panes of just under 90 chars side-to-side in VSCode, with a normal-smallish font. Am I in such a minority?

From the comments here, I guess we are so. I have a 1080p 14 inch laptop and with Consolas at 15px and it's pretty much exactly 2 panes of 80 chars in vscode.

I would increase the limit if I can fit more though and I don't mind accommodating others who prefer a higher limit.

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

#190

Post by hinkley »

ak217 wrote: post #184

Can we please just settle on 120 columns as the new 80? It would make things so much more reasonable. I have to agree going wider than 120 makes things harder to read. 80, no, there is no way I'm going to voluntarily follow that standard - I will have to be forced into it, and I won't like it.

I recall deciding quite a long time ago that I was going to do 100 columns and not ask anyone. It was with great amusement that I noticed, not very long after, that JetBrains added/moved the default gutter warning to either 100 or 120 columns.

That said, I do 4 space indents and 100 columns, not either/or. 2 space and 100 is an invitation to excessive nesting over decomposition. If you insist on 2 spaces then I’m afraid I’m going to insist on 80 columns (and that you finally get off your ass and learn how to code).

Post reply on HN