
But no, 80-column terminals in 2020 isn't “reasonable” any more - oddline
https://lkml.org/lkml/2020/5/29/1038
======
js2
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 cpl). Those that
> liked the 35 cpl indicated that the short line length facilitated "faster"
> reading and was easier because it required less eye movement. Those that
> liked the 95 cpl stated that they liked having more information on a page at
> one time. Although some participants reported that they felt like they were
> reading faster at 35 cpl, this condition actually resulted in the slowest
> reading speed.

The Effects of Line Length on Reading Online News[1]

1\.
[http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng...](http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp)

For slabs of body copy, I like about 70 characters per line, but anything in
the 50-80 range seems good. I also think justified text is harder to read, due
to the lack of unique shapes to track on the right side of text — it's far
easier to lose your place._

[https://graphicdesign.stackexchange.com/questions/13724/reco...](https://graphicdesign.stackexchange.com/questions/13724/recommended-
column-width-for-text-reading-digital-vs-printed)

I still often code on a 13" Macbook where I can open a pair of side-by-side
windows in my editor with the dock on the side and get about 95 characters
into each window. I typically code in Python and use a 4 space tab and a font
legible to my 48 year-old eyes w/o reading glasses. On my external monitor, I
take advantage of the extra width to open additional windows.

So I dunno, still prefer 80-88 characters for coding, 100 max.

The grep thing seems like a red-herring. Use grep's -A, -B, and -C options to
get more context.

~~~
ogre_codes
> 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 width.

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.

But having the option to use longer lines when it makes the code more readable
is also valuable. Putting a fairly short, arbitrary limits on line length just
makes other parts of coding less pleasant, variable names in particular suffer
quickly when you can't make comparisons on a single line.

Where I work, we wrap lines at 120 characters but the overwhelming majority of
the code is less than 80 characters wide. Longer lines are reserved for if
statements with multiple conditions or ternary assignments.

~~~
naikrovek
> 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.

~~~
livesinhel
> 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.

Linters' line length rules solve a problem of useless bikeshedding and
introduce consistence to the code. This already helps everyone involved in
reading and writing the code.

~~~
naikrovek
If people were interested in stopping the bikeshedding, they would create an
editor that let everyone view the code however they please, and check in with
a consistent format that doesn't matter. Extensions for source control tools
and debuggers would quickly point to the token that caused an issue, for
example, rather than the line number.

Instead everyone just creates rules that they like, then force those rules on
everyone else as a power move, then use "this is for consistency and anti-
bikeshedding" as an excuse to keep their own preferences enforced on others.

And before anyone argues, I've seen it happen multiple times. I swear people
become team leads solely to force their preferences on others. They certainly
are fond of power trips, in my experience.

------
avodonosov
Optimal code line width has very little to do with monitor or window width.
It's more of an anatomical restriction: the resolution of the human eye and
the field of view.

For example, if we had 10 meter-wide monitors we won't be able to see them
entirely from a close distance. Increasing the distance will require to
increase the font, so the number of characters per line we can use doesn't
change much.

Not so long ago I showed a piece of code on a mobile phone to a colleague,
saying he should use shorter lines. He replied I need a larger display. When I
opened the same code on my desktop display the lines were not fitting the
editor window almost the same as on the mobile screen. (The angular sizes of a
mobile phone screen and individual characters on it are approximately the same
as of the bigger screen and characters on it because we keep phone closer to
eyes).

I currently work with a codebase where long lines are used and it is so
inconvenient. When I switch to some 80-cols code it is such a relief.

~~~
bsder
I would be more sympathetic to 80 column limits if Linux didn't have indent
set to 8 columns.

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

~~~
jml7c5
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.

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

~~~
ric2b
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.

------
DoubleGlazing
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 or a dot in a function chain. Wrapped lines could be
tabbed or visually flagged to let you know.

In other words there should not be am ideal line length for code, but instead
editors should be able to adapt to make life easier for developers.

Look at word processor documents, imagine how much of a nightmare it would be
if such documents had a hard limit of characters per line.

~~~
Terretta
> _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.

~~~
travisjungroth
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.

------
Arathorn
Fwiw, we use 120 columns for Riot/Matrix stuff ([https://github.com/matrix-
org/matrix-react-sdk/blob/develop/...](https://github.com/matrix-org/matrix-
react-sdk/blob/develop/code_style.md)) - 80 is incredibly constraining for JS
and JSX. The key metric is to ensure that a typical laptop can show two
screens side by side, without any ugly line-wrapping. Also, any wider and you
either end up having to scan a wide distance left to right (the same reasons
that newspapers use columns to be more legible) - and it also helps discourage
lots of nesting and cyclomatic complexity.

~~~
delaaxe
I've found 120 to be the sweet spot - it either fills a laptop screen entirely
or allows 2 open editors on a wide screen.

------
kstrauser
I couldn't agree more. Our company standard for Python line length is at 99
characters because that seems like a nice balance between wide enough to show
more information, but narrow enough that it tiles well. I think it's much
worse for readability to have narrow, tall blocks of code that you have to
scroll around in more.

------
TazeTSchnitzel
I spend a lot of time writing code on my laptop, and while that _could_
display two 100-column terminals side-by-side, I prefer to also be able to see
other windows on my screen while having text at a size that doesn't strain my
eyes.

~~~
catalogia
Even on very large high resolution screens, it's nice being able to tile that
many more files on the screen. I think 'narrow' source code is advantageous no
matter your display.

~~~
qchris
I agree with you to a degree, but one of my pet peeves about certain linters
and code formatting tools is when they take something that could easily be a
very understandable single line, and break it up into three or more lines
because that's what the normal rules look like. As a result, sometimes a 15-20
line function ends up being over 50 lines, and I end up not being able to see
the entire thing without scrolling.

~~~
leghifla
Also sometimes, long lines can more easily render the structure of the
program. Like when a function is called with many/long arguments several times
in a row, with varying arguments. If you have one line per call, you can
easily see that it is the same function and what argument is changing at each
call. If you rewrite each call as 5 lines, it is much more difficult to grasp
what is going on.

And when you need to change, say, the second parameter, you will see that the
same call is made n times, and not forget one in the process.

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

~~~
RHSeeger
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.

~~~
_ZeD_
How can you make a linter for this?

~~~
erik_seaberg
If the author thinks it's okay, and the reviewer thinks it's okay, a robot
that can't actually understand code doesn't need a vote.

~~~
SenHeng
The reason for the robot is to have an impartial judge where neither author
nor reviewer are okay with the opposing judgement. At the end of the day, a
human’s judgement cycle is better reserved for something of a higher
priority/use.

~~~
erik_seaberg
Both parties should be able to cede style arguments graciously. You can't
really _win_ the argument by quoting policy, only postpone the argument and
burn team goodwill.

------
u801e
I find as I get older that I need to use bigger fonts in order to easily read
code. Based on my terminal font, I can fit two windows side by side with 90
character line lengths, but if I have 3 windows, it would go down to 60
characters (though that's not something I commonly do).

I also find diffs that involve changes to shorter lines easier to read
compared to ones with longer lines.

I wonder what he now thinks about line length in email and git commit messages
(excluding things like logs, error messages, etc)?

~~~
JohnL4
I'm sorry, if you can no longer code in a 9-pt font on a high-DPI screen, you
have to quit. I don't write the rules.

------
theonemind
Optimal reading width is like 40-90 characters, and if I end up with an
excessively long line, often times, I’ll try to rewrite a bit, not just line-
break my first thought, but use it as a creative spur to write better.

Personally, I like 80 character lines. If I need more than 80 characters in a
line, I treat it as a code smell.

~~~
RHSeeger
> Optimal reading width is like 40-90 characters

That statement follows along the same line of thought that many people that
want 80 char lines have. That it's better because "it's optimal". I have yet
to see any significant study actually showing this to be true for the case of
something like code.

Personally, I like longer lines where they make sense, and shorter lines where
they make sense. But overall, I like a line configuration that lets me
understand as much as possible with one screen of lines. That's the same
reason I prefer short functions, because I can understand more in the same
screen space from a single function call (by the name) than I can if the same
code is inline.

------
Arch-TK
I don't get it. 80 columns was always short but it forced you to think about
your code when it got too long.

Contextually local variable names which go far above 10 characters and
contextually local function names which go far above 20 characters are almost
always misnamed. Nobody should struggle to fit at least within about 100
characters when they're focusing their code on clarity and simplicity.

Obviously this doesn't mean that you should rename your buf_size variable to
bsz or s. But you buf_size variable in a function called read_line shouldn't
need to be called line_buffer_size and if there's only one buffer should
potentially just be called size.

Then there's people in this post claiming that research relating to
readability of text don't apply to code because people don't read whole lines.
I only have to wonder if these people have ever read code they didn't write on
that same day or from a codebase they're already very familiar with. I read a
lot of code, it's part of my job, I need to read the whole lines so I can
verify that there's nothing horribly wrong. It makes it incredibly difficult
to read expressions when they can't fit within my visual field.

Yes, hard-wrapping code is not great, it should be avoided and only done with
a good bit of experience, insight and awareness of how it's going to affect
the code. Regularly making your code 150 lines long because your variables are
repeatedly telling me information I could have just gathered from looking two
lines up and because your function names are descriptions of the behaviour of
the code they contain isn't a great look either.

Although I still think that my least readable experience was having to read
and work with code which used a 2 space indent (and an editor which wouldn't
let me fix this in any way) which regularly went 10 levels deep and 100s of
lines long.

------
vincent-manis
I long ago concluded that arguments over line width, indentation, etc. are a
waste of time. If I were submitting a kernel patch, I'd follow the Linux
standard without complaint, regardless of my preferences.

That said, the best argument on line length is “the magic number 7, plus or
minus 2”, our limits on short term memory. I like to be able to comprehend a
line of code (or of text) in one glance, which seems to me to be about 65
characters, ignoring leading indentation; that might well be less than about
10 tokens. With wide tabs, that might well hit something around 90 characters,
perhaps.

IMHO, it's not the line length that matters, but the number of tokens per
line.

By the way, I like to work on laptops. If anyone knows where I can get a
laptop with a 43" screen, please let me know.

~~~
data_ders
ooo i love idea of tokens per line idea. do you mean distinct words per line?
or conceptual objects you have to juggle in your head?

------
shockinglytrue
Typical ill-considered comment from Linus, and surprising for someone getting
on his years. Column width _is an accessibility issue_.

I'm barely in my mid 30s and the average font size has been steadily creeping,
maybe 1.5 pts per 5 years.

I could tolerate 132 column files today, but by the time I'm 50 there is no
way this will work, regardless of screen size

~~~
gnarbarian
Buy a bigger monitor. Or get glasses. I'm 38, rocking a 43" 4k monitor.
There's so much room. Scale things up or down to your comfort level. It's a
pleasure if you use an editor like atom.

~~~
dingaling
> I'm 38, rocking a 43" 4k monitor. There's so much room.

There's no more room on a 43" 3840 x 2160 monitor than there is on a 32" 3840
x 2160...

~~~
zapzupnz
That's fine. The point is that the font size is no issue at 43". Could be
really small, you'd still be able to _see_ it well.

------
Fiahil
I guess most of us, pragmatic people, agree that 80 columns is not a sane
standard anymore.

The more interesting question is "what would be a good default line length in
2020?"

I vote for 120 columns.

~~~
zajio1am
I would say that 120 is too much - for 1920px (still widespread resolution)
and split screen (2x120), one would need 8px-wide font to fit and no other
borders. 8px-wide font is IMHO not enough for good readability, even VGA in
198x switched to 9px-wide fonts (from EGA 8px-wide fonts).

Next natural values are 106 (for 9px fonts) and 95 (for 10px fonts).

~~~
Twixes
Few use bitmap fonts today, especially with retina displays and whatnot

------
williamdclt
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?

~~~
fzeroracer
No, I currently work on a single screen laptop right now as well due to
lacking the right cables to put together a multi-monitor setup.

I always feel like when people advocate 'no 80 column terminals period'
they're arguing from the standpoint of having never had to use anything
smaller than an ultrawide resolution display or three+ monitors. Larger lines
are almost unreadable on my screen and any sort of word wrapping only makes it
worse, so often I'm stuck with one file open at a time slowly jumping between
files.

80-column terminals as someone else brought up is an accessibility issue.

------
saagarjha
I'm a big fan of softwrapping. Not because it's inherently prettier or
something, but because the results are consistently better on more platforms
because they can softwrap at what you've set the column width to be and not
some arbitrary number someone thought was a good idea. (I have a similar
argument for using tabs, but I digress.)

~~~
u801e
This is what Linus has said in the past regarding soft-wrapping:
[https://github.com/torvalds/linux/pull/17#issuecomment-56611...](https://github.com/torvalds/linux/pull/17#issuecomment-5661185)

~~~
mekkkkkk
Ironic that his reply is almost unreadable on mobile because of his hard
wrapping. Intentional?

~~~
u801e
Github provides an email to Github comment gateway. So he was composing his
replies in his email client.

~~~
williamdclt
And his email client hard-wraps at 80 chars, because that's the standard of
both Linux and Git mailing lists, because they send patches in emails. I like
the irony :)

~~~
voodootrucker
> patches in emails

Cringe.

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

~~~
williamdclt
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 whatever is dead simple.

Honestly, the only 2 arguments I see for this process are "that's what we
always did and we don't want to make the effort to switch" and "having a high
barrier keeps newbies out and we don't consider it a bad thing"

~~~
u801e
> 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.

~~~
Avamander
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?

~~~
u801e
> that process is obsolete, cumbersome, finicky and convoluted.

It just sounds like you don't like the process since you apparently aren't
able to express a specific issue with it.

Here's what I don't like about Github

1\. You need to set up an account on there (I already have an email account)

2\. You need to fork a repo rather than just simply cloning it.

This means you have to go through a rather convoluted process to keep your
fork up to date with the original repo. That either involves setting up
another origin pointing to the original repo and then pushing up those changes
to your forked repo (and taking into account any branches you updated). Or you
have to delete the forked repo, fork it again and then have to somehow resolve
possible conflicts when running git pull.

3\. It's not possible to comment on a commit message itself

This means that I need to comment on the first line of the diff for that
commit or I have to edit the url to navigate to the commit itself and then
type stuff into a comment box at the very bottom of the diff.

Then that comment doesn't show up with any context other than saying "github-
user commented on abcdef1". And those comments disappear when someone force
pushes to the branch to update the commit. If the comment is associated with
the first line of the diff for that commit, it either is collapsed or not
depending on whether the line changed. I still have to go to the commit view
to check whether the updated commit message addresses my comment.

4\. It collapses comment threads when the line of code changes regardless of
whether the change pertains to the original comment.

This means I have to scroll from the top of the conversation view page and
search for collapsed comment threads to find the comment I made, then go to
the diff view to compare that line with what's in the current diff to
determine whether the change actually addresses a comment I made

5\. It's not easy to jump between different revisions of the branch over
several force pushes in a way that makes it easy for me to see what changed on
a per commit basis

6\. It doesn't provide a way to distinguish different subthreads of
conversations on the same block of code

7\. It requires far more scrolling in the conversation view when there are a
lot of comments on a pull request

As for email, all I need to do is

1\. Run a few git config commands to set up git to send email using my
existing email account (this is a one type step)

git config --global --add sendEmail.smtpServer "your.server"

git config --global --add sendEmail.smtpServerPort 587

git config --global --add sendEmail.smtpEncryption tls

git config --global --add sendEmail.smtpUser "your.email.username"

2\. Clone their repo, check out the appropriate branch, make your own branch
and do your work

If the upstream repo is updated while you do you work, you can simply run git
fetch and rebase your local branch on top of the updated branch, which is a
lot less convoluted compared to what you have to do to keep a Github forked
repo up to date.

3\. Create your patch files with cover letter

git format-patch --to email.list.address --cover-letter base-branch

4\. Edit the cover letter file and update the subject and body to include your
patch series description (which isn't much different than composing the PR
description on Github)

5\. Run git-send-email to send your patch series to the email list

git-send-email *.patch

6\. Check your email for replies, engage in addition discussion, etc (which is
better than having to scroll through a large diff to find every comment)

7\. Update your code, rebase

8\. Run git format-patch the same way but add -v2 to indicate a reroll

9\. Run git-send-email and reference the message-id of the original cover
letter

In terms of engaging in discussion over email, one can reply inline and
comment on any part of the cover letter, commit message, line in the patch
etc. One can save the emails from multiple patch series, run git am to apply
them in different branches locally and run git diff or git range-diff to check
what's changed. That's not possible in Github if someone force pushes to the
branch because there's no longer a remote branch to fetch to allow for a
comparison.

In any case, I would certainly be interested to read your specific complaints
about the email based process instead of just a dismissive reply.

~~~
williamdclt
Not answering your points against GitHub, they're valid and I mostly agree on
them.

About your "for email all I need to do is": this looks simple and neat (and
even then, does it really?) when you already know how it works. But it took me
several hours of googling around to understand what I was supposed to do (I
need to configure _git_ to _send emails_?), how to do it (get the right
sendEmail config is non-trivial), learn about multiple git commands I never
heard about and never used outside of this process (format-patch, am, send-
email) and their various flags, iterate to get the correct flags while
quadruple-checking everything to make sure I don't send garbage on the mailing
list and bother everybody, get told I didn't respect a half-dozen conventions
(no HTML in emails, 80-char lines, format of the commits, the email subject
and the cover letter, people CC'd...), iterate several times to finally have a
patch that respects enough conventions that people are OK looking at it. I had
to _change my email client_ because it's basically impossible to respect these
conventions or follow discussions without a specialised client à la Mutt,
which meant more hours downloading, configuring and learning a new tool. And
then I get feedback fragmented over several emails instead of a single
interface, spend a ridiculous amount of time answering to make sure you
respect conventions, never have a clear resolution of a feedback.

I submitted a copy change patch about a year after my first patch, and it
still took me hours to get it right.

The process you're explaining makes sense and seems simple when you are
already familiar with it. When you're not, it's just hours of head scratching
and trying to make sense of it. Which would be fine if that was a process
everybody used, we'd just learn it and practice, but nowaday very very few
projects use it: I've never had to go through all these hoops ever again.
Which makes it a crazy high barrier to entry and feel old and obsolete. And
maybe the high barrier to entry is considered a good thing by git/linux
people, it's their right, but let's not pretend it doesn't exist

~~~
u801e
> About your "for email all I need to do is": this looks simple and neat (and
> even then, does it really?) when you already know how it works

At one time, I didn't know how it worked, but I read through the documentation
(man pages for git, git format-patch, git send-email, and git am).

To be fair, when you create a new repo or fork a repo, Github will display the
commands necessary to set your repository's origin or cloning the repository.
It probably also tells you the commands necessary to push commits to the
remote or pull from it.

There is documentation out there that gives you a general idea about how to
submit patches, coding conventions, etc in [1]. It certainly would be nice if
they added a short tl; dr section on how to configure git for using the
format-patch and send-email commands (similar to what I did in my previous
post).

> get told I didn't respect a half-dozen conventions (no HTML in emails,
> 80-char lines, format of the commits, the email subject and the cover
> letter, people CC'd...),

This is all documented in the SubmittingPatches file in the git repo itself in
the Documentation directory. The maintainer and major contributors have to go
through a lot of submitted patches and they, for better or worse, will apply a
filter on what they accept. But reading through a text file to learn the
conventions and requirements shouldn't be considered a barrier to entry.

> while quadruple-checking everything to make sure I don't send garbage on the
> mailing list and bother everybody,

The best way to do that is to test it against your own email account.

> I had to change my email client because it's basically impossible to respect
> these conventions or follow discussions without a specialised client à la
> Mutt,

A GUI client like Thunderbird would have worked for viewing threaded
conversations and participating in them. In fact, there are a number of GUI
email clients that support threaded view [2] (but would need to be configured
to only send plaintext email). Submitting patches, on the other hand is best
accomplished by using the format-patch and send-email commands since they
ensure correct formatting. But the project could certainly do a better job
documenting the actual set of commands and flags used for generating the
patches and then submitting them (along with re-rolls). But the lack of
concise documentation for the settings and workflow isn't something that makes
the email workflow inferior or obsolete.

> then I get feedback fragmented over several emails instead of a single
> interface

The feedback is on a per commit basis. A patchset consisting of multiple
commits can make for a large diff and make it more difficult to review (and
require far more scrolling to view the diff and the comments in the Github
conversation view). An email client with an index view of the commits along
with their associated comment threads makes it easy to see which comments have
been read or not, what you've replied to, etc.

> Which makes it a crazy high barrier to entry and feel old and obsolete. And
> maybe the high barrier to entry is considered a good thing by git/linux
> people, it's their right, but let's not pretend it doesn't exist

I guess the real argument comes down to whether reading documentation and
reading through the mailing list before submitting a patch should be
considered a high barrier for entry. Regardless of whether a project is
managed via email, Github/Gitlab, or some other tool like Gerrit or
Phabricator, there are always some conventions to follow in terms of code
organization, style, commit message conventions, etc. At some point, one will
have to learn by observing how things work from previous submissions and/or
read through the documentation. There may be people who are willing to lead
others through the process and show them what to do, but, that's not always
the case.

I guess you could think of it as joining in a game that people are playing
(soccer, basketball, poker, etc), but not knowing the rules. You could either
read up on the rules beforehand and watch how they play before joining in or
just start participating and learn as you play. But if you keep making
mistakes and not respond to feedback, then others will be less inclined to
work with you.

[1]
[https://github.com/git/git/tree/master/Documentation](https://github.com/git/git/tree/master/Documentation)

[2]
[https://en.wikipedia.org/wiki/Comparison_of_email_clients#Ge...](https://en.wikipedia.org/wiki/Comparison_of_email_clients#General_features)

------
aimor
I'd rather have 80 columns on a 4:3 ratio than 120 columns on 16:9. "A wide
monitor is for" watching video, playing games, and putting larger diagonal
numbers on the box. I miss turning one monitor sideways to nearly fit an
A-sized document. And I miss those 120 extra vertical pixels from before 1080
became the standard. I think the only good and common option right now is 21:9
in a large size and resolution, you still won't get 1600 vertical pixels like
with a 3:4 but 1440 is still useful and there's enough horizontal space you
won't get distracted over nonsense like how many characters wide a line should
be.

~~~
bjoli
I would gladly pay twice the price for a 4k 4:3 or 3:2 monitor. Even on wide
displays, I rarely split top-to-bottom more than once. More vertical space
would mean a lot more usable screen estate for me.

~~~
zapzupnz
So just turn a 16:(9/10) monitor sideways. Plenty of vertical space.

~~~
bjoli
Two of them next to eachother makes for 16:18 which is my kind of screen!

------
spion
Here in JavaScript land, we have Prettier and can configure the line limit to
be whatever we want on our local editor and whatever else we want when we save
the saved file, making this entire discussion irrelevant.

Its time for more development tools to be built with individual developer in
mind, adaptable to their workflow and needs. See for example
[https://old.reddit.com/r/javascript/comments/c8drjo/nobody_t...](https://old.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/)

------
hirundo
The critical viewing scenario is two files displayed side by side. This is
very useful, but having to side scroll makes it less useful. So when choosing
an optimal maximum line width per file, pick an optimal display width and cut
that in half.

And if I'm a coder on your team, please pick the optimal display width using a
12 inch 1080p laptop screen. Also, pretend that your vision isn't 20/20\.
Thank you.

Bottom line, 80 columns isn't unreasonable.

------
alex_young
Isn’t there some merit to the notion that long lines are typically either
overly verbose or mentally challenging to understand?

~~~
colechristensen
Splitting one line into many because of character limits can also make an
action overly verbose or mentally challenging.

In some cases, unreasonable gymnastics needs to be done to get 80 character
lines, turning good variable and function names into shorter worse ones or
adding functions just to hide characters.

~~~
Normal_gaussian
most languages support simply adding "visual" newlines in the middle of a
"logical" line; I tend to do this to improve readability - could this be done
to avoid your long lines?

~~~
colechristensen
Sometimes, but not always.

I often do it too to improve readability, but it doesn't always actually
improve readability. Sometimes it takes something which makes logical sense to
have in one line and arbitrarily breaks it up in awkward spots over several
lines.

If you squish code into 80 characters wide, you lose vertical density, making
a set of actions more difficult to understand by separating steps.

------
stickfigure
The problem here is that our editors aren't smart enough to wrap code
appropriately. Word processors know to wrap lines on word boundaries; a smart
code editor should be able to wrap lines and indent parameters in a human-
pleasing way as you drag a window wide or narrow.

~~~
saagarjha
I think most editors these days do a pretty decent job? It's not perfect, of
course, but 99% of the time it's fairly readable.

~~~
wallacoloo
More generally though, there's an argument to be made that line-wrapping
should be a thing your editor does as part of the rendering process -- not a
thing it encodes into the actual source file.

Modern languages come with excellent auto-formatters which can make the code
look nice at just about any line length. What we need to do is integrate the
auto-formatting into the editor (likely via a language-server) so that it can
adjust to the width of the editor dynamically instead of running it directly
on the files at some width that's forced to be the same for every user of the
codebase in every setting.

~~~
williamdclt
We could stop storing code as text, just store an AST and let the editor parse
it and render it respecting the preference of the user

(I think this is a terrible idea, but also got me thinking if there's
something interesting there)

~~~
falcolas
> We could stop storing code as text

Why is this terrible? Syntax errors would no longer exist, it would allow
editors to work directly with the AST and not text... I think this is a fine
idea personally.

Our current editors already try to do this - letting you work with syntax and
not text - via smart completions, boilerplate templates, and syntax
highlighting. Working with an AST directly is only taking it a step further
(and better, it removes the reliance on context-insensitive regex based
tooling in the editors).

------
wozer
I hate it when zealot coworkers reformat code to 80 columns. It almost always
gets much less readable in the process.

~~~
rantwasp
agree with them that there should be a limit and set it to 120

~~~
wozer
yes, 120 seems reasonable

------
camgunz
I’m an 80 cols person, and I admit to be low-key enraged by wide lines. I
really like having lots of side-by-side editors and a terminal, and long lines
bust that, and I resent what feels like a lack of sensitivity for others’
workflows in many modern tools that generate wide lines.

That said, I try and practice what I preach and let my coworkers who are into
wide lines (120, _woof_ ) have ‘em. I just run a formatter after I check code
out, ez. Everyone should do this, online diffs should default auto format to
80 cols (but configurable), and we should put this debate to rest.

~~~
kstenerud
Why should online diffs auto format to 80 cols? Shouldn't that be up to the
user?

~~~
camgunz
Sorry I ninja edited you. Diffs with wide lines don’t always fit on screens;
but if you have a wide monitor, set it to 400 for all I care.

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

~~~
pas
Using softwrap when looking at diffs seems natural. After all you already rely
on tools to show you the meat of the diff, the changed lines, and preferably
the tokens inline.

Plus I find that most of the time I just use the default patch view, not the
side by side one when doing review.

------
thangalin
France named Basile Bouchon invented a way to control a loom using perforated
paper tape in 1725. The descending lineage can be traced to 80-column
terminals:

[https://dave.autonoma.ca/blog/2019/06/06/web-of-
knowledge/](https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/)

In his Elements of Typographic Style, Robert Bringhurst suggests that 66
characters per line, including spaces, for single-column pages is optimal:

[https://dave.autonoma.ca/blog/2020/04/11/interior-book-
desig...](https://dave.autonoma.ca/blog/2020/04/11/interior-book-design/)

What studies have reviewed code quality versus line length? Or eye fatigue
versus line length? Or comprehension versus line length? Are their any studies
that attempt to approach optimal line length empirically?

My preference is to indent 2 spaces rather than 4, which allows a lot of code
to fit within 80 columns. When and why did 4 spaces became the norm?

~~~
chj
4 spaces allows you to have manual line wrapping, for example: if (a < b || b
< c || ... || d < e || ... ) Do something.

------
vjeux
It's ironic that he's wrapping the text of this email at 80 columns rather
than letting the email reader do the wrapping based on the width.

~~~
ordu
Text and source code in a programming language are different things. Most
lines in source code do not fill line from start to end. And there are a lot
of almost empty lines (in terms of count of non-space characters). It is easy
to navigate through this by eyes. But when you got a rectangle filled with
characters it is much easier to get lost.

------
cdelsolar
He's wrong. I can barely fit 80 characters on each panel when I split my code
window into two on my Macbook Pro. Any more and I wouldn't be able to see the
whole line, or would have to grow eyes that can see tiny fonts.

~~~
nathanyukai
He's not wrong, he just doesn't care for your use case. Get a monitor or don't
have two terminals side by side.

~~~
cdelsolar
my use case is extremely common.

------
978e4721a
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.

~~~
dragonwriter
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.

------
wilg
Many programmers are averse to line wrapping plain text files (especially
source code), which has never made much sense to me. There's great support for
it in like every editor.

~~~
serf
linewrap is aesthetically and logically jarring when you're debugging code 'by
shape'.

peaks and valleys between functions and such are a huge aid visually -- line
wrapping makes visualization of source code harder for myself, personally.

~~~
lelandbatey
That's only a problem if you're using a line-wrap method which doesn't account
for indentation and just blindly wraps (which yes, is awful). If you want to
have nice indentation aware plain text line wrapping, your text editor almost
certainly supports it.

If you use vim, look into the "breakindent" option.

If you use Emacs, you can use the "adaptive-wrap" package with a configuration
like this:

    
    
        ;; Indentation of softwraped code
        (use-package adaptive-wrap
          :ensure t
          :init (defun my-activate-adaptive-wrap-prefix-mode ()
                  "Toggle `visual-line-mode' and `adaptive-wrap-prefix-mode' simultaneously."
                  (adaptive-wrap-prefix-mode (if visual-line-mode 1 -1)))
          (add-hook 'visual-line-mode-hook 'my-activate-adaptive-wrap-prefix-mode))

------
jacobsenscott
If there so some tool everyone uses that constraints the width use that.
Otherwise treat programmers like grown-ups and let them break their lines
where they want.

The width of a github code window is about 120 characters. That's suggested
max line width because horizontally scrolling diffs during a code review is
terrible. It is rare that we have any lines close to that long though.

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

------
LargoLasskhyfv
I never understood this fetish. Using workstations with graphical
framebuffers, which even had the system console in whatever was hires then,
setting the system console to 132x60 in text mode on 21 inch for FreeBSD was
one of the first things i did. That punchcard inspired technical limit was
something to overcome, not to embrace.

------
egypturnash
Damn this sure is not what I expected Linus to be saying, I seem to remember a
previous lengthy, swear-filled rant from him about why the Linux sources
require a line break at 80 characters and why this is absolutely perfect and
sensible and will never ever change and you are a moron for suggesting
otherwise?

I may be imaging this, I dunno.

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

~~~
hinkley
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).

------
waynecochran
I'm an old programmer that still has the 80 character limit burned into my
frontal lobe. But I reached an age where I don't waste anytime worrying about
these things. I am surprised Linus is such whiner about this.

------
chj
In fact, I try to go even narrower, because almost every time my editor ends
up with at least 3 columns. By the way, indentation with more than 4 spaces
wide is why you get long lines. Don't do it.

------
swiley
Most people consider 40 ems the maximum readable line length, that’s half of
80 columns.

At least at work, I feel like my 80 column terminal is probably the only
“reasonable” app as far as layout and readability go.

------
robbrown451
I'm all for soft-wrapping. I sometimes cram windows side by side so I can see
more files at once, and sometimes spread them out so I can see more of a file
at once. I move and resize windows as the need arises.

And I really don't want to spend brain power thinking about where to wrap
things. I was glad that word processors made it so I didn't have to think
about carriage returns after about 1981 (yes I learned to type on a mechanical
typewriter), and glad I stopped having to think about it in source code around
2010.

------
robomartin
If I remember correctly, DEC, Tektronix, Honeywell, Qume and other real
terminals moved to 110 characters per line in their later generation
terminals.

Coming from the perspective of that era I never understood the obsession with
80 characters per line.

I can honestly say that I have never limited my code through such artifice,
ever.

I can give examples of code where artificially breaking things into 80
characters makes an absolute mess out of things. Complex table-driven state
machine lookup tables and FPGA I/O definitions come to mind, among others.

------
ceocoder
Here is Rob Pike on 80 column limit[0], I’ve seen folks having to go through
just crude gymnastics to make 80 column check for pep8/flake8 before someone
inevitable disabling that chek/or add ignore check for that line. One think I
love about gofmt is it does not give a rats behind for how long a line should
be.

[0]
[https://twitter.com/rob_pike/status/563801489190043648?s=21](https://twitter.com/rob_pike/status/563801489190043648?s=21)

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

------
nathan_long
On my 15-inch MacBook, I have a full-screen terminal running tmux, split down
the middle with Vim in the left pane and a shell in the right pane. At the
smallest font size I can stand in decent lighting, I can get 88 columns in the
left pane. Usually I want the font larger.

80 seems good to me.

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

------
Jaruzel
One of the first things I do, on _every_ Windows box/session I use, is change
the Command Prompt defaults from 80x25 to 132x50. It's about time Microsoft
updated the default tbh (and also switch the default to something more
modern).

------
dboreham
A vt-100 could do 132 columns and I've always set my terminal windows to that
width.

------
mD5pPxMcS6fVWKE
I think the famous rule for short memory capacity (we can on average keep 7
words/numbers/objects in out short memory) should also apply here. Up to 7
words/operators per line, up to 7 lines for a function etc. are optimal.

------
Aloha
I started using a 132 Column wide terminal about 15 years ago, then I
increased the vertical size so its 132x25, then x30, then x40 - and for some
special service stuff I'll make it even bigger yet.

------
throw0101a
"Does Column Width of 80 Make Sense in 2018?":

* [https://news.ycombinator.com/item?id=17436945](https://news.ycombinator.com/item?id=17436945)

------
zajio1am
Personally, i limit line length to 95 columns - 1920 / 10px wide font / 2
(horizontal split screen) is 96, minus some pixels for borders.

------
lmilcin
Nothing really changed about Linux kernel that would require columns to be
wider.

The only things that changed are developers and their developer setups. We got
better, wider monitors and we got used to using longer variable and function
names.

80 characters is an arbitrary constraints that requires me as a developer to
think how I am structuring my code. It also makes it easier for me to read the
code as 60 characters is about perfect column width for readability.

------
pauljurczak
We had only at most 72 positions available on 80 column punch cards, and we
loved it! Bring back the 1950s! ;-)

------
alkonaut
Or just accept that a few lines in a code file or log is longer than the
screen.

Don’t use wrapping, it destroys the layout (of a log etc).

Just scroll to see the rest of the line! You scroll down to see any lines that
aren’t on screen, why would (occasionally) scrolling right be worse?
Readability is some times worse with wrapping.

If you want to answer “but my terminal can only trim or wrap, not scroll!”
then perhaps that’s a relic just like the 80 wide display?

------
nickdothutton
Old enough to remember 132 column line printers and using them to do code
reviews. It felt very convenient.

------
jofer
I'm a bit fan of usually wrapping at 80, but not requiring it in a linter.

Do what makes the most sense for readability, but often lines significantly
over 80 characters are more readable as two lines.

I typically work with multiple horizontal splits open. That's part of why I
prefer 80 characters. However, I really do feel that a soft break at about 80
is good for readability, and certainly easier with larger fonts.

------
cbm-vic-20
I keep my VT420 in 132x39 mode, but it does take a little longer to redraw the
screen at that size.

------
ridiculous_fish
Text has solved this problem without requiring hard line breaks at regular
intervals.

------
SparkyMcUnicorn
I'm hoping that one day I'll be programming in AR or VR, unbound from the
limits that come with a statically positioned (and sized) screen.

There's still a lot of issues that need to be solved, but I'm hopeful all the
pieces will come together in a relatively short amount of time.

------
elihu
I think 80 columns is a bit narrow for modern monitors, but still lines
shouldn't be excessively long either, so you don't waste screen real estate on
vast expanses of white space. Something in the neighborhood of 100 to 120
columns is probably about right these days.

------
winrid
This!! At <current_company> people are insisting we use a max of 80 columns
for the linter. It's a huge pain compared to 100 or 130 columns and doesn't
help readability.

Everytime someone tries to argue for it I want to suggest we swap their Mac
for a Commodore 64...

~~~
u801e
Well, the C64 had a 40 column display width for the BASIC interpreter, but I
think it was possible to have statements that wrapped and could go up to 80
characters (I may be wrong about that though).

~~~
winrid
The more you know! Thanks.

~~~
saalweachter
The VT100 is commonly considered the origin of the standard terminal size,
although I've seen pedantic historians take it several steps further and
sideways.

------
madhadron
A friend of mine was legally blind. Keeping lines to 80 (or 88) characters was
a way for him to be able to deal with text with a huge magnification. So keep
to 88 characters, please. Not everyone has good eyes.

------
seemslegit
That email sure seems to be formatted for 80 columns

------
jftuga
I guess his new AMD CPUs can now handle the wider columns!

:-)

------
jedisct1
I like 128 because it’s a round number.

------
briandilley
I wonder how Linus feels about tabs vs. spaces (I didn't read the entire post,
so maybe he addressed it?)

~~~
saagarjha
The kernel uses 8-space tabs.

~~~
ccmcarey
How do you mean 8 space tabs? Are tabs not single characters \t?

~~~
ordu
You can customize your text editor to show them as any number of spaces.
Mostly people prefer tab-stops at each forth or eighth column.

~~~
dezgeg
In practice you get problems, because of the line length rule.

I.e. if your editor is configured with four-space tabs and a line with one
leading tab shows up in your editor having 79 characters, it will show up as
83 characters for others assuming the normal 8-space tabs thus breaking the
line length rule.

Not to mention that coding style may require that function calls broken to 2
lines must have the arguments aligned at the opening parenthesis.

For example, breaking up foobarbaz(1, 2); into two lines would require having
the second line start with <TAB><SPACE><SPACE>2); which would no longer look
correct with 4-space tabs.

~~~
eMSF
>Not to mention that coding style may require that function calls broken to 2
lines must have the arguments aligned at the opening parenthesis.

That doesn't result in any problems with using <TAB>s, unless the coding style
also requires you to replace all (leading) sequences of N spaces with with a
<TAB>, which is, IMO, quite brain-dead. For example,

    
    
        if (cond) {
        <TAB>foo(1,
        <TAB><SP><SP><SP><SP>2);
        }
    

looks fine regardless of the width of <TAB>.

Admittedly, your first problem remains; a problem with dumb editors. In truth,
your editor could well signal if your lines exceed the limit (indent-
width*indent + rest) you have set for your project, just as easily as it can
draw a line at a column.

The harder problem is that you need a context-aware editor for it to help you
with indenting. Most editors are incapable of that by default.

~~~
dezgeg
> unless the coding style also requires you to replace all (leading) sequences
> of N spaces with with a <TAB>, which is, IMO, quite brain-dead

It is brain-dead, but that is exactly what is required in many styles.

------
SergeAx
I really like this wiser version of Linus. Imagine that text five years ago)

------
imglorp
Good riddance. If we pick a new suggested width, maybe it shouldn't be based
on a 1928 punch card standard.

------
CalChris
I agree that 80 is too small in 2020, and hasn't been since around 80x25=2000,
but LLVM is stuck at 80 columns [1]. I'd be interested to see a canvas of
other big projects.

[1] [https://llvm.org/docs/CodingStandards.html#source-code-
width](https://llvm.org/docs/CodingStandards.html#source-code-width)

~~~
truncate
Looking at examples, they also seem to have 2 space indents. Google C++ Style
Guide also uses 2 space indents.

I've never measured it, and my observation is very likely biased (as I've
mostly worked with C++), but I've found 80 columns in big C++ projects often
very limiting. Maybe less often now, after people are most accepting to new
features; e.g type inference `auto` over
`MyNameSpace::BlahContainer::const_iterator iter`.

