You don't read code the way you read a book or long-form document, as authors generally don't optimize for vertical reading.

Details matter.

The way I'm set up at my desktop, my editor can fit ~320 columns. Which means I can fit four 80-column-wide files side by side. Three, if you account for line numbers on the margin.

(I usually do two, because my code tends to go up to ~120 characters.)

The more reasons to use narrower lines, right? I mean, I work in two files side by side 50% of the time, and with 120 chars the text would require wrapping, which is really unreadable in e.g. python.

Personally, I prefer handling long lines via horizontal scrolling (with keyboard shortcuts) rather than wrapping.

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

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.

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.

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.

I somehow forgot to add the essential part of my comment. Sorry, here it is:

If someone prefers a narrow tab width and breaks lines based on that, then someone who prefers a wide tab width will get overfull lines:

    20 column limit, 2-column tabs:
    if (a==b) {         |
      if (b==c) {       |
        some_function();|

    20 column limit, 4-column tabs:
    if (a==b) {         |
        if (b==c) {     |
            some_functio| <- overfull line

Either way, the project has to set some sort of official tab width. Or at least, a maximum tab width.

If you nest code that deep, you probably should extract some logic into separate functions.

I remember Linus saying that explicitly.

> It's more of an anatomical restriction: the resolution of the human eye and the field of view.

The restriction on code length to 80 has absolutely nothing to do with the resolution of the human eye or your 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.

Again, this isn't relevant to the question of say, 80 cols vs 100 cols vs 120 cols. No one seems to be saying cols should be unbounded in length.

> Not so long ago I showed a piece of code on a mobile phone screen 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. (We keep phone closer to eyes so can use smaller characters).

I'm not sure how this is an argument for 80 cols other than the already addressed "I limit my development environment to 80 cols".

I have a certain monitor width, distance from that monitor and font size. Those constraints dictate how many open file columns I can fit across my screen. I'm happy if I can get two columns, so that I can edit files side-by-side. 80 columns is the approximate sweet spot.

The suggestion that people should just get "better hardware" is so completely asinine, because it neglects to realize that the quality of hardware might not be the problem. For example, instead of having a single very large monitor, I use three somewhat smaller monitors because that enables other productive workflows.

He never said to buy better hardware. He said the code should no longer be formatted based upon what he believes to be a niche situation. People in this situation can, in fact, still edit code. You will get line wrapping. It's not optimal, but neither is editing 80 lines when you have 100 available.

You missed my point. My point here is that reasonable people can disagree if you just take a second and think about others' perspectives, workflows and development setups. But no, Linus is literally arguing that reasonable people cannot disagree because he's arguing that an 80-column limit isn't "reasonable." That's a bunch of bullshit.