Keeping your lines of code under 80 columns is still valid advice in 2022.
- GitHub forces you to scroll horizontally for long lines.
- Some people do code reviews on their cell phones.
- Who are you to claim all my screen real state?
- Long lines aren't very readable anyway.
Somewhat trollish but mostly honest answer:
80-char-limit-lines is SO outdated and inefficient as general advice.
> _GitHub forces you to scroll horizontally for long lines_
Whut? Definitely not over 80 chars ([eg](https://github.com/tripu/superscript/blob/master/server.js#L55), [eg](https://github.com/tripu/glypher/blob/master/js/glyphs.js#L27)).
> _Some people do code reviews on their cell phones_
That sounds horrible to me. And in any case, it's not my fault. What if some people do code reviews on their smartwatches?
> _Who are you to claim all my screen real state?_
Shorter lines take exactly the same real estate (just distributed differently). And in any case, I'm not claiming anything: you can enable line wrapping (and scroll).
> _Long lines aren't very readable anyway_
Perhaps. But over 80 chars isn't always “long”. In certain languages there are typically long identifiers and long chained properties (eg, Java). Add four or five levels of indentation, and you're well over 80 before you realise it. Splitting that one line into two or three shorter lines may well make that _less_ readable, not more.
- GitHub: Maybe it's around a 100 columns. Even if you make the browser take the whole screen.
- I once or twice did code reviews on the phone before boarding a plane. There are apps for GitHub and GitLab. People use them.
- I want my screen to see the code and the browser side by side.
- Java culture sucks. Class names of 40 chars.
"if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program."
–Linus Torvalds
https://www.kernel.org/doc/html/v4.10/process/coding-style.html
> _GitHub: Maybe it's around a 100 columns_
Nope. [This](https://github.com/tripu/superscript/blob/master/server.js#L55) is > 140 chars long, and doesn't truncate or wrap.
> _I once or twice did code reviews on the phone before boarding a plane. There are apps for GitHub and GitLab. People use them._
C'mon… You said it: “once or twice”. I feel your pain. 99% of people shouldn't compromise 99% of the time because of those rare use cases. People try all kinds of crazy devices and clients.
> _I want my screen to see the code and the browser side by side_
Personal preference/need. I sometimes want to see the console underneath — for that, fewer longer lines preferred. (And again: [local solutions](https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap) are easy.)
> _“If you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program”_
That's wrong (breaking news: Linus has been known to be wrong before):
1. _“Tabs are 8 characters, and thus indentations are also 8 characters.”_ That's half of the problem, right there. 8 chars? No wonder they want < 4 levels. 4 levels × 8 chars = 32 chars = 40% of your very conservative line length budget!
1. A class → a method → an `if` = 3 levels. No room for a loop, for a literal object with properties, for chained calls split into different lines for legibility? I seriously doubt Torvalds himself follows that rule.
1. I looked for popular projects on GH with files with more than 3 levels of indentation to prove my point. There aren't many: it's ALL of them.
I'm more sympathetic to that argument.
And still:
1. There's no hard-coded limit; it's completely screen-width-dependent. Zoom out and see longer lines. Or reduce your font size, or use a larger monitor.
1. Switch from “split” to “unified” view. eg, from [this](https://github.com/facebook/react/pull/25699/files?diff=split) to [this](https://github.com/facebook/react/pull/25699/files?diff=unified). (Although “unified view” is less usable, yes.)
1. Click “hide file tree” (even less usable).
/cc @gasull
