68 comments

  • js2 1399 days ago
    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...

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

    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 1399 days ago
      > 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 1398 days ago
        > 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 1397 days ago
          > 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 1394 days ago
            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.

        • labawi 1398 days ago
          > Arbitrary rules like line width help exactly 0 people per day

          I use a linter, it warns about long lines (adjusted to 100), so I reformat or split them and the code seems more readable. Also, it has consistent formatting (other rules), though I occasionally mark some lines to be ignored.

          I'd say it helps me, which is >0 people. You don't have to follow norms and/or best practices, but some find it useful.

        • ogre_codes 1398 days ago
          > 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 have no idea why you think I am arguing for stuffing arbitrary line lengths in code. I was arguing for the exact opposite, that line length limits are rarely beneficial.

        • shultays 1398 days ago
          When is shadowing is right thing to do? Why picking a new variable name wouldnt work?
          • naikrovek 1398 days ago
            No matter what I say here, I feel it would be very likely you will tell me I'm wrong.
            • shultays 1398 days ago
              I am skeptical but curious. I honestly can't think of one. The closest one I can think is maybe you have some kind of macro that uses a temp variable? like a swap macro? But i think you can still have a unique variable name for that particular line if you want?

              But if these cases are exceptional then you can use pragma to suppress those warnings for that particular block of code. If they are not exceptional perhaps you shouldn't have enable the warning/linter check for that warning.

              But honestly I can't think a good reason for shadowing variables and would appreciate an example

      • ThrowawayR2 1398 days ago
        > "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.

        • deepspace 1398 days ago
          To be fair though, if you have class names like AbstractSingletonProxyFactoryBean, then terminal width is the LEAST of your problems.
          • im3w1l-alt 1398 days ago
            You may be in a position where using a verbose framework or libraries save you way more effort than the small pain they bring.
            • yellowapple 1397 days ago
              You may also be in a position where you can alias those names to something more reasonable.
        • ogre_codes 1398 days ago
          Just skimming our codebase, 20+ character variable names are fairly common. Even with verbose variable names, the majority of our lines of code are less than 80 characters. Probably 1 our of every 15-20 lines of code stretches longer and we greatly appreciate that we can go longer, but the majority are shorter.
      • l0b0 1399 days ago
        Another reason the assumption that style rules for natural language is transferrable to code is kinda baffling. I wonder if there's ever been much research in this space which doesn't make that assumption.
        • taeric 1399 days ago
          It is more than just natural language. You could look at math journals, for their jargon. Music notation. Recipes.

          Really, is there any writing that doesn't seem to apply?

          • fauigerzigerk 1399 days ago
            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 arbitrary rule, you are misleading readers into looking for meaning where there is none.

            • taeric 1398 days ago
              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.

              • fauigerzigerk 1398 days ago
                >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.

                • taeric 1397 days ago
                  My point was that there is no writing that extends to long lines. If anything, the fact that no other writing form has made such extensive use of indentation is enough to give me pause and think if that is making any sense. (I do note the amusing lines in the Linux style guide on the use of heavy indentation.)

                  And looking at this before I hit go. You seem to ultimate be agreeing. Taking opening indentation into consideration concedes that long lines are bad. You just give some room for margins. And are ok with all of the mental stacking that the indentation implies.

      • rmrfstar 1399 days ago
        > If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems

        In math-heavy stuff, lines tend to be longer. You are usually trying to convert one line of math into one line of code. I myself shoot for 160 character columns.

        See, e.g. [1].

        [1] https://docs.fast.ai/dev/style.html

        • ogre_codes 1398 days ago
          I agree, math is a perfect example where code is more clear to have a single long statement on one line. I am a bit skeptical that you have a big codebase with math on more than a quarter of the lines of code though. Most likely there are a lot of shorter lines between your formulas which is exactly my point here.

          When long lines improve readability/ clarity you should have the ability to use them.

      • JoeAltmaier 1399 days ago
        Tell that to 'functional programming' people, or the lambda-crazy people who put entire functions in argument lists to the point you can't parse a statement to save your soul. I've had to print and highlight code to figure out where it began and ended.
        • ogre_codes 1398 days ago
          > ...who put entire functions in argument lists to the point you can't parse a statement to save your soul.

          As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code.

          • u801e 1398 days ago
            > As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code.

            Isn't perceived difficulty of reading code correlated with how familiar one is with the language it's written in? For example, code may be harder to read for someone who lacks experience or is new to the language, but it's not difficult for someone who is experienced and is familiar with the language.

        • dkersten 1398 days ago
          I mainly use Clojure and keep most of my lines under 80 characters.
      • dragonwriter 1398 days ago
        > Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line width.

        No, it doesn't, especially for code that isn't written in a very basic simplistic imperative style. Expressions have no natural size limits (and statements, in languages that even have them, can generally each contain one or more expressions.)

        Languages tend to develop conventional line width limits and conventions for where to prefer to break within expressions to achieve them, but there is no natural length limit to the length of a single statement.

    • vlovich123 1399 days ago
      Is there any research to suggest that reading legibility of code is the same as for regular text? Unlike regular text code often has special characters & indentation to break it up, so intuitively I would assume it could support longer line lengths.
      • stock_toaster 1399 days ago
        Yeah, we cant forget whitespace (indenting, space alignment, etc).

        In a 100 char wide code line, how many actual non-whitespace chars would there be on average?

      • chipotle_coyote 1399 days ago
        I was wondering the same thing, yes. I'm often an annoying stickler about keeping line length for text on the web set to what a couple centuries of book design have taught us makes long-form prose more readable, but code is not prose. I try to keep multi-line comments wrapped to around 78 characters, but I'm not really too worried about code.

        (This invites a rant about people, usually people who use Emacs, who put hard line breaks in text paragraphs, but I'll save it for another time.)

    • ssivark 1399 days ago
      It really doesn’t matter.

      We must strive to separate content and presentation, so people could choose whatever presentation they like (and have the editor do the wrapping as desired), for whatever whimsical reason that is nobody else’s business. It’s crazy to keep having this discussion and debating what the “research” indicates.

      C’mon, haven’t we made any progress in forty years!? Everybody can have their own damn bikeshed, and paint it a different color every day.

      Personally, I like to see more things happening in one screenful, so artificially imposed line breaks are really really annoying and break momentum when reading/scanning code.

      • fouric 1399 days ago
        This. The problem itself has nothing to do with the number of characters you have on a line - the problem is that the vast majority of programming tools today conflate content and presentation.

        The job of making sure the line length is reasonable is not up to the writer of the code - it is up to the tools that are used to read it. Lines should be as long as necessary, and then intelligently (i.e. syntactically-aware) soft line-wrapped by the editor when opened.

        • enriquto 1399 days ago
          > the problem is that the vast majority of programming tools today conflate content and presentation.

          This is not a problem, but a beautiful and crucial property of text files. I like the principle that "a program is a text file", that you can edit with tools orthogonal to the language in question

          • rbanffy 1399 days ago
            With that in mind, you are free to reformat the file to your tastes on checkout and do it with repo-compliant standards on commit.

            If I did work for Google, with their heinous 2-space tabs, I'd certainly do that all the time.

          • wolrah 1399 days ago
            > I like the principle that "a program is a text file", that you can edit with tools orthogonal to the language in question

            Adjustable tab display width and automatic line wrapping are features any good text editor offers that do not interfere with the use of any other text manipulation tools on that file.

            Now, if you're forced to work in an environment where someone wrongheadedly decided to adapt to users who have bad or badly configured editors and standardized on space indentation that sucks, but that's the fault of whoever made that bad decision.

        • dkersten 1398 days ago
          I try to keep my Clojure code under 80 characters (so that I can have three editors comfortably side by side at my preferred font size) and keeping lines short is more than just where to wrap or other visual-only things. Usually when I have a long line, it makes me reconsider the structure of the code and I refactor it into something else. Most of the time, the new structure not only has shorter lines, but is simpler too, so its a double win. This isn’t always a task that the tools could do for mem, though, as it sometimes rewuires rethinking what I’m trying to accomplish.
      • justaguy88 1399 days ago
        Ah so you're "tabs" haha
        • wolrah 1399 days ago
          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...).

          To me that is a significant objective advantage of tabs, where the only advantage spaces seem to offer is that you can align text on multiple levels of indentation.

          • PunksATawnyFill 1398 days ago
            Yep. I have yet to hear a coherent argument against tabs.

            It’s such a tiresome squabble.

            • sam_lowry_ 1398 days ago
              Douglas Crockford made an interesting argument in favour of spaces: https://www.youtube.com/watch?v=En8Ubs2k1O8
            • ric2b 1398 days ago
              Vertical alignment of related lines.
              • dkersten 1398 days ago
                If you indent with tabs, you can still align with spaces for vertical alignment.
              • PunksATawnyFill 1397 days ago
                That’s the whole point of tabs. How is this an argument against them?
                • ric2b 1395 days ago
                  Because it doesn't work with tabs, someone else will have a different tab-width.
    • nicoburns 1399 days ago
      Shirt lines have the problem that they make it much more difficult to scan the whole document for someyhing because they increase vertical distance. You can fit less on the screen at once.

      I actually prefer long lines even if I have a small screen and need to horizonally scroll. Often the content at the end of the line isn't even that important.

    • manquer 1399 days ago
      Unlike text in print, code is not a paragraph, in typical code every line is not going to be that long. I am not sure the same rules can apply.

      I find that breaking a line at 80/120 makes the piece of code I am trying to understand less readable, while the line itself may have become more readable.

    • ryandrake 1399 days ago
      The problem with this idea is you then get these web site designers who take it as dogma and try to force a particular width, without regard for the browser window size. This results in sometimes 1/2 or more of the horizontal area on the page wasted by this giant white space border. If you must have a margin, at least make it a reasonable percentage of the browser window width. Or better yet, don’t force my browser to render a margin.
      • hinkley 1399 days ago
        Somewhere I have a picture of daringfireball taking up around a quarter of the monitor width and just blank space around it.
        • zapzupnz 1399 days ago
          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.

          • charrondev 1398 days ago
            > that Windows users are prone to do.

            Or how iOS users tend to do.

            • zapzupnz 1398 days ago
              Indeed. I was thinking about iPads, but I didn't mention it because the design predates iOS — but yes, it's absolutely true.

              And he hasn't optimised the design for iPhone-sized devices much but I think that's deliberate.

    • TheDong 1399 days ago
      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 line-oriented (same for sed, etc). Sure, it's possible to make the output have context, but to actually do a multi-line grep correctly is much more complex.

      I think that's the sort of grep usage linus was referring to.

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

      I also prefer most lines to be under 80 characters, but for the sake of keeping a function call on one line, or keeping important things together, I'm fine with exceptions.

      Some code splits onto multiple lines naturally (like moving a function call in a function's arguments into its own temporary variable). Other times, it becomes less readable as several shorter lines.

      Thus I don't think a hard rule of 80 is good, simply a general philosophy that readable code is good and that's more important than line length.

      • joshuamorton 1399 days ago
        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 you reprocess with AST-based tools.

        There's some fairly ergonomic tooling for this kind of transformation, although often you need a tool per language, which is annoying.

        • saagarjha 1399 days ago
          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…
          • _ZeD_ 1399 days ago
            Or... You can use and ide for this... (Eclipse have generic text and specific programming search for that)
      • williamdclt 1399 days ago
        I do this sort of grepping regularly, and would love a more code-oriented tool. Ignore whitespace, integrate syntax notions...

        For example for a function foo, it's needlessly hard to grep for its declaration, imports and calls independently. Looking for one will probably surface the others.

      • addicted 1399 days ago
        I have a fairly simple solution for the scenario you’ve presented. grep, and return some context (maybe +5) and then grep on that again with the argument you’re looking for (give a negative context this time so you get the entire function call)

        That being said, as unlikely that scenario is, having it all in 1 line does not work either. The problem is that its very likely/possible that the true argument will be passed in in the form of a variable. So you’re back to needing something that is more code aware anyways.

      • tomxor 1399 days ago
        > where 'true' is split onto a newline, that naive grep misses it.

        This misses the point, same as Linus (which i honestly find surprising)... 80 width lines is a target to try to achieve _naturally_, if someone is splitting code by inserting unnatural breaks then they are trying too hard, OR there could be various other legitimate reasons like very long function names and naturally verbose PL syntax that make even longer line widths unreasonable. Regardless of width constraints many people will split the arguments of extremely long function signatures onto multiple lines out of preference anyway, then grep will still get stuck without more caring regex.

        These arguments always emerge out of someone misinterpreting guides as absolutes. No one is arguing we need to stick to 80 column terminals otherwise everyone would autowrap their commits and we'd have horribly unreadable breaks everywhere. 80 is historical, but trying to keep code width short does improve legibility, 80 just turned out to be a pretty good human standard as well.

        • zapzupnz 1399 days ago
          > This misses the point, same as Linus (which i honestly find surprising)... 80 width lines is a target to try to achieve _naturally_,

          The post is about changing code style formatting rules for code that goes into the Linux kernel. Not guidelines, rules. The tools in question, I presume to be a linter or formatter, complained noisily about line length prior to the adoption of this change.

          It's not about someone misinterpreting guides as absolutes. It's very much about absolutes, in this case, that serve as guides.

          • tomxor 1398 days ago
            > The post is about changing code style formatting rules for code that goes into the Linux kernel. Not guidelines, rules.

            Then it is about absolutes, the rule is absolute, but 80 width is a guide... being used as a rule.

            I'm surprised the first to challenge the rule is about grepability and not how detrimental it is to legibility to use this as a hard rule.

      • moonchild 1399 days ago
        Then pipe through

          perl -pe 's/\\\n//g'
        
        Before grepping
        • wool_gather 1398 days ago
          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.
          • moonchild 1398 days ago
            No? That just merges continuation lines. So if your original file is

              foo(1, \
                  bar, \
                  false)
              print("Hello, world")
              flag = \
                  true
            
            Then the postprocessed output is:

              foo(1, bar, false)
              print("Hello, world")
              flag = true
            
            And your grep output is just

              foo(1, bar, false)
            • wool_gather 1398 days ago
              Sorry, what language are we talking about that has escaped line continuations for expressions like that?
    • GuiA 1399 days ago
      Yeah, when you do typesetting you quickly learn that ~10 words per line is a sweet spot for readability.
      • lostmyoldone 1398 days ago
        I wonder what the equivalent of 10 words is for code in <programming language> ?

        The large number of symbols in many languages that are clearly not words in the usual sense might make the comparison a bit tricky, or wouldn't it ?

    • yellowapple 1397 days ago
      > 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.

      This is indeed why a large number of books and articles and papers opt for multiple-column formats.

      Frequent line breaks also help better break up distinct pieces that warrant independent examination, much like how such breaks in poetry help isolate distinct thoughts. There are certainly cases where such a "thought" does indeed exceed that 80-line limit, but I've found that they are rare (though this obviously depends on the language; for example, in my day job my T-SQL code frequently exceeds that arbitrary limit, simply because it often takes more characters to express a "thought").

      All that being said, I wouldn't impose this on an existing project. If Linux's standard is for 100-character lines, then that is the standard to which I'll adhere. For my own code, however, 80 characters is (language limitations notwithstanding) more than sufficient.

    • cdaven 1396 days ago
      > Reading rates were found to be fastest at 95 cpl.

      They only tested 35, 55, 75, and 95 characters per line (cpl)! Which means that if they had tested 120 cpl, THAT could have been "fastest".

    • 978e4721a 1398 days ago
      Yeah, bad tools shouldn't justify bad decisions. Build better tools god damn it.
    • KODeKarnage 1399 days ago
      One line, one idea. That's the goal. Your eye doesn't need to move if you can get the information you need from the first 30 characters. Two lines, one idea. That's a recipe for cognitive disaster. It forces you to read the entirety of the preceding line to understand what is happening on the next one. As a good example, reading logs. You can scan down the log to find what you want. Imagine if the time was placed at the end of the line. It doesn't matter how many characters on a line in that case, the reading the log is a massive cognitive load.
  • avodonosov 1399 days ago
    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.

    • threatofrain 1399 days ago
      You don't read code the way you read a book or long-form document, as authors generally don't optimize for vertical reading.
    • TeMPOraL 1399 days ago
      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.)

      • demosito666 1399 days ago
        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.
        • jabirali 1399 days ago
          Personally, I prefer handling long lines via horizontal scrolling (with keyboard shortcuts) rather than wrapping.
    • bsder 1399 days ago
      I would be more sympathetic to 80 column limits if Linux didn't have indent set to 8 columns.
      • ASalazarMX 1399 days ago
        This was a solved problem with tab indenting. It's a bit unfortunate that space indenting won, but I understand why.
        • catern 1399 days ago
          What do you mean? Linux uses tabs.
          • ASalazarMX 1398 days ago
            Winning doesn't mean completely extinguishing the competition.
        • jml7c5 1399 days ago
          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 1399 days ago
            Why would that be a problem? That's the point, that you can set tab width any way you want.
            • ric2b 1398 days ago
              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.
          • PunksATawnyFill 1398 days ago
            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.

            • jml7c5 1389 days ago
              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.
      • rbanffy 1399 days ago
        If you nest code that deep, you probably should extract some logic into separate functions.

        I remember Linus saying that explicitly.

    • bcrosby95 1399 days ago
      > 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".

      • burntsushi 1399 days ago
        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.

        • bcrosby95 1398 days ago
          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.
          • burntsushi 1398 days ago
            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.
  • DoubleGlazing 1399 days ago
    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 1399 days ago
      > 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 1399 days ago
        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.
      • jsolson 1399 days ago
        Xcode on OS X has been doing this for at least one decade.
      • grok22 1398 days ago
        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).
    • zeroimpl 1398 days ago
      This would make debugging hard, as debuggers are very much line number based. Step commands move one line at a time, breakpoints are for specific lines, and stack traces from exceptions include line numbers but not character offsets.

      That’s why for function calls passing multiple arguments where each argument may be non trivial, it’s a good idea to put each argument on its own line.

      • yellowapple 1397 days ago
        The editor could show both the final line number and "sub-line-numbers" after a decimal point or something. E.g.:

            1   /* A function that does something */
            2.1 int do_something(int foo,
            2.2                  int bar,
            2.3                  int baz)
            2.4 {
            2.5     return foo + bar + bam;
            2.6 }
        
        Which would condense to:

            1    /* A function that does something */
            2    int do_something(int foo, int bar, int baz) { return foo + bar + bam; }
        
        When you try to compile this, the compiler will complain about line 2, which you know from your editor's line numbering encompasses lines 2.1 through 2.6. As an alternate strategy, you could use column numbers instead of sequential sub-lines, like so:

            1    /* A function that does something */
            2.0  int do_something(int foo,
            2.26                  int bar,
            2.35                  int baz)
            2.44 {
            2.46     return foo + bar + bam;
            2.70 }
        
        And then, if the compiler reports a column number or offset into the line, you'll immediately know "well the compiler's complaining about line 2 column 65, which is between 2.46 and 2.70... golly gee willikers, I fat-fingered the third addend in the return statement!".

        You could get even more abstract than this, with "line numbers" instead being local to a given scope, and the compiler reporting erroneous line numbers relative to said scope. If the compiler tells you that the syntax error is in the first (in this case also last) statement in the function do_something, then it should be apparent where to look.

      • Semaphor 1398 days ago
        Not always. I can set the breakpoint in jetbrains rider to a function in a multi function line. And Java stacktraces certainly contain character offsets.
        • zeroimpl 1398 days ago
          I’ve seen character offsets for JavaScript (which requires it due to minimization), but never Java. I’m pretty sure that data is not available in Java bytecode, nor most compiled languages.
    • falcolas 1399 days ago
      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.

      • smabie 1399 days ago
        No text editor that I know of intelligently word wraps code. Vim doesn't and Emacs doesn't either.
        • fiddlerwoaroof 1399 days ago
          If you modify breakat and a couple other options (foldindent, to make the autowrapped lines stand out from the others), you can make vim’s autowrapping a lot nicer for word-wrapping code.
        • bryanrasmussen 1399 days ago
          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.

          • sesuximo 1398 days ago
            I think it’s pretty simple. Word wrap the way a N-character wide linter would
            • 0-_-0 1398 days ago
              Yes! Someone please make this a reality!!
    • EsotericAlgo 1399 days ago
      Is it an issue of editors or of language? The amount of errors that incorrect whitespace characters cause in whitespace sensitive languages could attributed to editors obfuscating what's written to file.

      I think the pragmatic solution is an opinionated linter that can be broken.

    • sesuximo 1398 days ago
      Now that you’ve said it you have to make it happen!
  • Arathorn 1399 days ago
    Fwiw, we use 120 columns for Riot/Matrix stuff (https://github.com/matrix-org/matrix-react-sdk/blob/develop/...) - 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 1399 days ago
      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.
    • JMTQp8lwXL 1399 days ago
      80 works fine for JSX if you have linter rules that put each prop on its own line, for when you have >80 characters of content.
    • whycombagator 1399 days ago
      Nice

      120 is also what I've settled on & am used to. But I'd be equally OK, and adjust fine, with anything from 100-120.

    • JohnL4 1395 days ago
      Interesting. I, too, use 120. It makes diffing code easier.
  • kstrauser 1399 days ago
    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 1399 days ago
    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 1399 days ago
      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 1399 days ago
        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 1399 days ago
          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.

        • ncmncm 1399 days ago
          Yes, lining up arguments in a deeply indented column is criminally wasteful. Whitespace is a limited resource, to be applied where it is useful. Splattering it everywhere leaves nothing to use to unobtrusively direct attention where needed.
      • TazeTSchnitzel 1399 days ago
        Yes, and human eyes are bad at tracking lines beyond a certain length.
  • juanbyrge 1399 days ago
    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 1399 days ago
      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_ 1399 days ago
        How can you make a linter for this?
        • erik_seaberg 1399 days ago
          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 1398 days ago
            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 1397 days ago
              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.
        • alanbernstein 1399 days ago
          Use warnings for long lines instead of errors?
        • pas 1399 days ago
          Annotate the long line to ignore that particular linter rule. This makes it clear that it's not because the coder was lazy, ignorant, etc.
          • zeroimpl 1398 days ago
            Wouldn’t that make the code less readable?

            I think the point is that if 98% of your code fit under 110 chars when you weren’t using a linter, then maybe you don’t need a linter checking line length.

            • pas 1397 days ago
              You can disable the max line length rule too.

              I find linters helpful. Just yesterday it helped me catch a serious bug in Python. After fixing all linter warnings. The last one was a unused variable. Turns out it should have been used.

              Sure, the line length is not as severe as a unused var, but that's why the important thing is to have a systematic approach to thinking about maybe-problems that the "compiler" doesn't care about.

    • krferriter 1399 days ago
      I think a lot of terminals just set that as the default window width. No real reason for it, I usually snap to half the screen width immediately anyways. That turns out to about 105-120 characters width. Some people might just not resize it most of the time. Especially on Mac where efficient window management just isn't a thing.
      • winrid 1399 days ago
        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! :)

        • kstrauser 1399 days ago
          The #3 productivity app on the Mac App Store is a $2 app that enables this on Apples: https://apps.apple.com/us/app/magnet/id441258766?mt=12
          • thedirt0115 1399 days ago
            Hammerspoon can do this (and way more!) for free :)

            https://www.hammerspoon.org/go/#winresize

            • andai 1399 days ago
              I ended up with Hammerspoon when looking for an AutoHotKey alternative. Highly recommend.
            • kstrauser 1399 days ago
              Oh, nice! I really prefer the window dragging method, though, and it doesn't seem like Hammerspoon supports that.
          • sorum 1399 days ago
            It’s _literally_ the first app that gets installed on a fresh machine for me.
          • winrid 1399 days ago
            I'll have to try this.
        • ObsoleteNerd 1399 days ago
          Have you seen Powertoys[0] FancyZones? It’s honestly in my top 5 Windows 10 apps of all time and it’s free. Fully customisable window zone manager allowing different zone layouts on each monitor and with hot key support.

          This should be standard in Windows IMO. It has absolutely transformed how I work and noticeably increased my productivity.

          [0] https://github.com/microsoft/PowerToys

        • chipotle_coyote 1399 days ago
          I've gotten used to doing that not with the mouse but keyboard shortcuts, using an, um, let's call it venerable third-party Mac program called Moom. Moom has a drag-to-snap feature similar to Windows' functionality, but whenever I enable it, I find myself constantly resizing windows by accident. This is funny to me only in that it seems really ironic that as a long-time Mac user who's been known to argue with the "only use the keyboard" crew over the relative virtues of pointing devices, this is something I do way better with the keyboard.
        • _jal 1399 days ago
          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 need to see anything, or waste an inflexible chunk of screen on it.

        • JoshTriplett 1399 days ago
          I use keyboard shortcuts for that: Win+left and Win+right will maximize a window on that half of the screen. That makes it easy to quickly have a terminal or editor on one half and something else (like a browser or PDF) on the other half, using only the keyboard.
          • andai 1399 days ago
            To clarify, these are built in (everyone running Windows has them).
          • winrid 1399 days ago
            Yeah I typically use keyboard shortcuts for them too, good point!
        • ken 1399 days ago
          macOS has supported left-and-right snapping ("Split View") since 10.14. Maybe your accidental demo was the inspiration!
        • rbanffy 1399 days ago
          Macs have been doing that for ages.
  • u801e 1399 days ago
    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 1395 days ago
      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.
    • g7r 1399 days ago
      Yes! The thing about line width limit in terminal isn't about display resolution and size only. As a man who prefers big characters due to conditions I always vote for lower line width limit. It is starting to get really uncomfortable on lines longer than 100-120 chars.
  • theonemind 1399 days ago
    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 1399 days ago
      > 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.

    • lostmyoldone 1398 days ago
      For non whitespace text that might be a good figure but it doesn't automatically imply that the same would be true for the full width indented text.

      I don't personally feel that the indentation most programming languages employ have any effect at all on my reading, unless possibly it's too narrow as code is partially read as a graphical construct. Hence limiting the length of the entire line to an equal width seems unnecessarily restrictive.

    • thiht 1397 days ago
      40 chars is unreadable. I have a buddy who writes all his mails wrapped at 60 chars and it's already a pain to read.
  • Arch-TK 1399 days ago
    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 1399 days ago
    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 1399 days ago
      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 1399 days ago
    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 1399 days ago
      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.
      • cgriswald 1399 days ago
        I generally agree. My allergies really mess with my near vision, which is otherwise very good. My needs change. Should everyone else have to change how they do things to meet my changing needs? We have the technology to make any line length equally accessible to everyone.

        We should be focusing instead on the contextual and cognitive pros and cons of various line lengths.

      • dingaling 1399 days ago
        > 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 1399 days ago
          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.
        • lostmyoldone 1398 days ago
          Yes it is if you physical ability to resolve pixels (eyesight) are less than the DPI of the smaller monitor, which I take to be what was what the top poster shockinglytrue meant by his age related character point size increase.
      • michaelmrose 1399 days ago
        Is it a TV? If so does it work well for small text and are there any negatives vs a monitor?
        • lostmyoldone 1398 days ago
          There are 43/42.5" monitors that aren't too expensive, but if you want much bigger you will have to go TV, which can work okay as long as they support a reasonable colorspace encoding that enables quick enough color changes between pixels. Unless the TV supports RGB, you'll want to make sure it supports YUV/chroma 4:4:4.

          The refresh rate might be slower, so of you get annoyed by a 30Hz refresh rate, you'll want to make sure the TV does 60Hz.

          Nowadays I'm guessing anything but the cheapest models can do it for any given resolution, but some diligence is probably in order as TV specs are not as uniform and reliable as monitor specs.

      • shockinglytrue 1399 days ago
        What kind of laptop bag do you use for the monitor?
    • graton 1399 days ago
      Well Linus is 50 years old. So I expect he also suffers from age related vision problems. So I don't think he is unaware of it being more difficult to read text as you get older.
    • okareaman 1399 days ago
      I'm 62 and don't normally wear glasses, but reading glasses have become a big part of my life. I use 1.0 to look at my big screen, 1.75 to look at my phone and always misplace them somewhere.
      • dboreham 1399 days ago
        Head to Costco and buy three three packs of the diopter strength you loose. It'll take a few years to loose 9 pairs and if you bust them out of the pack when a pair is lost then you always have a scratch free pair.
      • falcolas 1399 days ago
        As "nerdy" as they look, the CliC brand readers (that separate magnetically at the nose, and that wrap around the back of your head with a solid band) are remarkably good at sticking with you as you move around in the day. 1.0's at the computer, 1.x around your neck.

        Sadly, they don't make them with anything under 1.25.

    • klingonopera 1399 days ago
      > "the average font size has been steadily creeping, maybe 1.5 pts per 5 years."

      To be fair, so has the monitor resolution and its density. I'm looking at HN, and imagine, ten years ago, I was using 1280x1024 then, this very font would've physically been a much bigger picture. So in effect, the font-size increase may only counter-measuring the resolution increase...

      • bscphil 1399 days ago
        > the monitor resolution and its density

        On most operating systems, this is supposed to be almost irrelevant since they use a "virtual" resolution and DPI that gets used to render apps at a reasonable size across displays.

    • dekhn 1399 days ago
      Do you need reading glasses? I found I did (I'm 47) and it made a massive difference in looking at code- I can use a smaller font and experience much less eye strain.
      • jacobsenscott 1399 days ago
        I've also been buying a larger monitor every few years, as the prices drop.

        But I hated the 42" 4K I tried and returned it. The problem was the edges are just too far away. If I use them I end up with the same kind of neck strain I would get with a multi-monitor setup. So I only used kind of the middle section of the screen anyway. And at 42" 4K the physical pixels are just too big - everything is fuzzy.

        32" 4K is the sweet spot for me. Maybe when there's a reasonably priced 42" 8K curved display I'll give it a go.

        • leghifla 1399 days ago
          Do you know if your neck strain is due to horizontal or vertical movements? On a few times I had to work with big monitors (>30"), I noticed that I placed/sized windows only at the center, and not all the way to the top. Looking up too much is not comfortable for my neck. For the horizontal movement, I have no problem. But when my eyes are focused on the centre part, if I need to look at the extreme left/right, I need to refocus, which is slow/tiring.

          My work setup is 2x24" monitors, and I really prefer 2 small ones instead of a bigger one. I can orient them so that all pixels are approximately at the same distance to my eyes.

          • jacobsenscott 1397 days ago
            The vertical was definitely more uncomfortable than horizontal.
      • gnarbarian 1399 days ago
        Yes this. I have 20/20 vision but as I got older getting some mild reading glasses dramatically improved my development experience.
    • thawaway1837 1399 days ago
      Well, Linus has already said he doesn’t care about your (or anybody else’s) accessibility issues.

      Is the kernel getting impossible to compile on anything less than a monster $2500 gaming rig? Too bad. Stop being poor or from a poor country.

      Does the code require a $1000 monitor to be readable? Same.

      Do you need a larger size font because of age? Well pop your Benjamin Button polls coz Linus Torvalds dont care.

    • SECProto 1399 days ago
      > I'm barely in my mid 30s and the average font size has been steadily creeping, maybe 1.5 pts per 5 years

      I'm a similar age, and my font size has been decreasing steadily. As monitors get better pixel density, text is readable at smaller size. The ereader app I use on my 5.6" phone screen shows 38 lines of text (and approx 45 characters wide) plus blank margins.

    • mikelward 1399 days ago
      Can't you enable line wrapping in your editor?
      • knolax 1399 days ago
        Line wrapping is an abomination.
        • falcolas 1399 days ago
          Visual line wrapping (that doesn't modify the code) is just fine. Works a treat for prose and notes, and if you combine it with a toggle to switch to horizontally scrolling lines, it works remarkably well.
        • mikelward 1399 days ago
          Horizontal scrolling (a.k.a. side scrolling) then?
  • Fiahil 1399 days ago
    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 1399 days ago
      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 1398 days ago
        Few use bitmap fonts today, especially with retina displays and whatnot
    • jacobsenscott 1399 days ago
      Github is the new fixed width terminal, and 120 columns is about right for that. That's our standard.
    • kakwa_ 1398 days ago
      I would vote for something around ~100 with a tolerance for ~130 (CI/linter warning if between 100 and 130, maybe with a threshold limiting the proportion of lines per file in warning so that the tolerance is not abused).
    • zenlot 1399 days ago
      Good line length for 2020 is 80 columns.
  • williamdclt 1399 days ago
    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 1399 days ago
      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.

    • squaresmile 1399 days ago
      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.

  • saagarjha 1399 days ago
    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 1399 days ago
      This is what Linus has said in the past regarding soft-wrapping: https://github.com/torvalds/linux/pull/17#issuecomment-56611...
      • mekkkkkk 1399 days ago
        Ironic that his reply is almost unreadable on mobile because of his hard wrapping. Intentional?
        • u801e 1399 days ago
          Github provides an email to Github comment gateway. So he was composing his replies in his email client.
          • williamdclt 1399 days ago
            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 1399 days ago
              > patches in emails

              Cringe.

              • bjoli 1399 days ago
                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 1398 days ago
                  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 1398 days ago
                    > 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 1398 days ago
                      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 1398 days ago
                        > 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 1397 days ago
                          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 1397 days ago
                            > 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

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

                        • Avamander 1397 days ago
                          > It just sounds like you don't like the process since you apparently aren't able to express a specific issue with it.

                          I don't like the process because it has so many issues. It's just hostile in so many ways if you aren't using a VT-100, it's fundamentally flawed because of the assumptions it makes.

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

                          I'm no longer interested in being specific because it's an evangelical issue, where the other side is just not interested in improving the process no matter how detailed you are, in the end the reply will just be "it's all so perfect, look how easy and nice it is". I also know that being specific with an evangelist will just get me a reply "oh just rent a VPS if your ISP blocks SMTP", I've played this game before.

                          Just like you just did. If you really can't admit to see a single fault with the system, you are evangelical. That's not necessarily a bad thing, but it doesn't really allow any discussion on the topic.

                          • u801e 1397 days ago
                            > I don't like the process because it has so many issues

                            And you still haven't described any of them.

                            > It's just hostile in so many ways if you aren't using a VT-100

                            That's a strawman. At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote. You're going to have to learn how to deal with code conflicts, resolve them and push up the resolution. You can certainly participate in the email patch workflow with a GUI email client and a few git commands either executed on the command line, or may be as part of a graphical git GUI client.

                            > where the other side is just not interested in improving the process

                            I already mentioned a few things in my reply to williamdclt pertaining to tl; dr documentation for setting up git format-patch and git send-email much like Github displays the commands to clone, set the remote, push and pull commits. But I don't think it's fair to say they're not interested in improving the process. For example, a new utility called GitGitGadget was written to provide an interface between Github pull requests and the Git mailing list and it's also mentioned in the Documentation folder of the git repository [1].

                            > in the end the reply will just be "it's all so perfect, look how easy and nice it is"

                            The problem is that you're being too dismissive in your criticism and comments rather than specifically describing what could be improved within their process. Effectively telling a project that they need to discard a process that they've successfully used since its inception and move to an entirely new process is a non-starter.

                            > I also know that being specific with an evangelist will just get me a reply "oh just rent a VPS if your ISP blocks SMTP"

                            Some people prefer to run their own SMTP servers rather than use Big Company's product. In my case, I have no problem doing this through the email account I have with my ISP.

                            > If you really can't admit to see a single fault with the system, you are evangelical.

                            I did mention in my other reply that the documentation for setting up the environment could be more concise, but not everything that's old is necessarily worse or obsolete. A lot of Webapps perform worse in terms of latency and input lag on my laptop with a multicore processor, gigabytes of memory and over a terabyte of secondary storage compared to the equivalent desktop application from decades ago on a machine with megabytes of memory, a single core processor running at less than a quarter GHz and secondary storage less than a quarter GB.

                            [1] https://github.com/git/git/blob/master/Documentation/MyFirst...

                            • Avamander 1397 days ago
                              > That's a strawman

                              How? That workflow assumes a 80-char b/w terminal for the most part. Try using any part of it on mobile or with large font size due to bad eyesight, it's awful.

                              > At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote.

                              Well... no, you don't have to.

                              > In my case, I have no problem doing this through the email account I have with my ISP.

                              In your case...

                              > The problem is that you're being too dismissive in your criticism and comments rather than specifically describing what could be improved within their process.

                              I have tried being very specific, just one sentence later you prove my point, it doesn't work and gets dismissed. I really don't plan on playing that game until I die of old age. Thankfully GitLab/GitHub et al have started the "fight" for me, making the workflows much more accessible and losing quite a few B/G-era relics.

                              > Effectively telling a project that they need to discard a process that they've successfully used since its inception and move to an entirely new process is a non-starter.

                              Yeah, this is exactly the answer I spoke about and have gotten, blanket dismissal and being set in old ways. There isn't a piece of workflow that they're/you're willing to move out of that toolset. Quite a few projects still enforce 80char columns, it's a testament to the fact that even the smallest things can't be changed.

                              > A lot of Webapps perform worse in terms of latency and input lag on my laptop with a multicore processor, gigabytes of memory and over a terabyte of secondary storage compared to the equivalent desktop application from decades ago on a machine with megabytes of memory, a single core processor running at less than a quarter GHz and secondary storage less than a quarter GB.

                              Yeah and you uploaded your patchsets for minutes if not hours. God forbid you had to download anything with any size at all, sometimes it took days. The non-stop hassle of having enough disk space. Delivering files via snail-mail and floppies was sometimes a viable option. Not to mention the equal amount of rather buggy and cumbersome software.

                              It wasn't all bunnies and flowers you are trying to imply it was. Some half-a-second slowdown, some minor input latency is not a valid reason to dismiss an entire set of tools. Not to mention, git doesn't really shine with it's responsiveness in quite a few cases.

                              • u801e 1397 days ago
                                > How? That workflow assumes a 80-char b/w terminal for the most part.

                                There's nothing stopping you from using a gui text editor to edit the code and there's nothing in git commits or the code itself that forces wrapping at 80 characters. Email clients certainly can wrap text at longer line lengths if configured to do so.

                                > Try using any part of it on mobile or with large font size due to bad eyesight, it's awful.

                                I don't try to do any serious development on my mobile. Having a machine with a reasonable size screen along with an actual keyboard makes things much easier.

                                If you're referring to hard wrapping, you're probably going to have to deal with that for most source code anyway no matter what line length. Soft-wrapping lines that exceed the screen width makes code and diffs less readable. For text in the email that doesn't require hard wrapping, there is an RFC[1] that defines a additional format parameter for the Content-Type header. Clients that support it will softwarp text, but email clients that don't will just show the original hardwrapped version.

                                > I have tried being very specific, just one sentence later you prove my point, it doesn't work and gets dismissed.

                                The git project, specifically, has been using this process since its inception (around 2005 IIRC). They inherited it from the Linux project which had been around for several years longer than that. In fact, the process pre-dates git itself and git was written with that process in mind (which is why they have commands that can serialize commits to and deserialize them from email).

                                But, like I said, telling a group of people as an outsider that they should drop the long standing process entirely which has been working well for them and go with something different isn't going to gain any real traction. This is regardless of the domain you're dealing with.

                                > Yeah and you uploaded your patchsets for minutes if not hours.

                                Most patch sets probably don't exceed several hundred lines total. Even on dial-up, you're talking about less than a minute.

                                > God forbid you had to download anything with any size at all, sometimes it took days.

                                Patch sets aren't really that big. The only thing that took a while with email or newsgroups was messages with attachments or having to download a lot of headers. As for git, the only process that may take a while is git clone. git fetch and dealing with email would work just fine over dial-up.

                                On the other hand, I seriously doubt that webapps like Github or Slack can work over dial-up speeds. For instance, if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable, but I can still receive and send email without any issues.

                                > It wasn't all bunnies and flowers you are trying to imply it was.

                                If you were talking about downloading images, mp3s, etc, then, yes, it took a while, but those things aren't relevant to text patches, email, or git.

                                > Some half-a-second slowdown, some minor input latency is not a valid reason to dismiss an entire set of tools.

                                I use Slack and Github Enterprise at work. On a 100 Mbps downstream connection, I have to wait for 10 to 20 seconds for a PR to load up when it has more than 20 comments. When I type in Slack, there's a noticable input lag that develops over time (on the order of seconds) and I have to refresh the Slack window several times a day to get rid of it). Sometimes, I try to mark messages as read and my browser tab freezes until it gives me a prompt about a script causing a slowdown. If I stop it, then Slack is unusable and I have to refresh the page to recover.

                                I simply don't recall having these issues with email or IRC (or even some of the other chat clients like ICQ, AIM, MSN Messenger, etc), and all of them worked perfectly fine over dial up and on machines that significantly less computation speed and available memory.

                                > Not to mention, git doesn't really shine with it's responsiveness in quite a few cases.

                                It really depends on what you're using git for. If you're storing large binary files or very big mono-repos, then it's not the right tool to use. Similarly, tools like Github aren't the right tool to use for certain projects that deal with many in flight patch sets that require in depth discussion and not having the platform shut down accounts of certain users due to issues the US government has with a number of other countries around the world.

                                [1] https://tools.ietf.org/rfc/rfc3676.txt

                                • Avamander 1397 days ago
                                  > there's nothing in git commits or the code itself that forces wrapping at 80 characters

                                  Very clever leaving out the third component here that does force it.

                                  > Email clients certainly can wrap text at longer line lengths if configured to do so.

                                  Assuming someone hasn't banally pre hard-wrapped the text.

                                  > I don't try to do any serious development on my mobile.

                                  Who said anything about serious development, you basically can't even check a patch out on mobile without some major hassle. Plus you also ignored the general accessibility problems.

                                  > If you're referring to hard wrapping, you're probably going to have to deal with that for most source code anyway no matter what line length.

                                  Source code can be displayed using a code viewer, nicely, it works. Comments can be displayed using a text viewer, using text fonts, nicely, it works. Non-HTML e-mail conflates the two, the resulting amalgam is vomit-inducing.

                                  > But, like I said, telling a group of people as an outsider that

                                  Nah, this reply is given to even insiders that don't want to deal with that obsolete shit.

                                  > they should drop the long standing process entirely which has been working well for them and go with something different isn't going to gain any real traction. This is regardless of the domain you're dealing with.

                                  I can say my ten-year-old laptop "works so far", but is it good, no, not really. It's really a rather weak argument to resist even changing the tiniest things.

                                  > if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable

                                  Fix your home network.

                                  > but those things aren't relevant to text patches, email, or git.

                                  You're still pretending that it was fast even with text patches, e-mails or git.

                                  > simply don't recall having these issues with email or IRC (or even some of the other chat clients like ICQ, AIM, MSN Messenger, etc), and all of them worked perfectly fine over dial up and on machines that significantly less computation speed and available memory.

                                  Yeah, you have other issues with IRC. Not to mention, no, they didn't "work perfectly over dial-up".

                                  > It really depends on what you're using git for. If you're storing large binary files or very big mono-repos, then it's not the right tool to use.

                                  It depends if you're using it or not. It's slow even on medium-sized repositories. Things don't happen in an instant like you pretend them to do.

                                  • u801e 1395 days ago
                                    >> there's nothing in git commits or the code itself that forces wrapping at 80 characters

                                    > Very clever leaving out the third component here that does force it.

                                    Which component is that? The SMTP protocol? According to [1], the maximum line length allowed by SMTP is 1000 octets, which is well over any maximum hard-wrapped line length for typical source code lines.

                                    > Assuming someone hasn't banally pre hard-wrapped the text.

                                    Hardwrapped text is only a problem for displays that cannot display lines as long as the hardwrapped line length. It's not a problem for displays that can display lines longer than that. To me that indicates that if enough people are using mobiles to read code and patches, then we should consider line length limits significantly less than 80 characters.

                                    > you basically can't even check a patch out on mobile without some major hassle.

                                    Mobile email clients are not suited for reviewing patches due to the fact that they typically use variable width fonts and do not provide a way to post replies inline with quoted text. But that certainly could be fixed by connecting to a machine and attaching to a screen or tmux session to review a patch.

                                    > Nah, this reply is given to even insiders that don't want to deal with that obsolete shit.

                                    Citation please.

                                    > I can say my ten-year-old laptop "works so far", but is it good, no, not really. It's really a rather weak argument to resist even changing the tiniest things.

                                    Changes should improve on what's there, not go off on a different tangent. Github wasn't even originally designed for code review and it shows. The fact that you can't have threaded discussions (like Hacker News or reddit, not like Facebook) or Twitter) on a line of code, treating commits as something completely dissociated from the review doesn't sound like an improvement to me.

                                    > Source code can be displayed using a code viewer, nicely, it works.

                                    Looking at my python code on Github on my mobile, I find that I have to scroll from side to side to view the code which is wrapped to 79 characters or less for most lines. That's no different than viewing it in a window that does not softwrap the code. How would this be any different than viewing an email with the softwrap setting turned off?

                                    >> if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable

                                    > Fix your home network

                                    Why can't those tools work when I'm getting 5 to 10 kB per second downstream? Email and IRC work perfectly fine. It's the same thing if I only have a GPRS connection on my mobile. You might call protocols other than HTTP obsolete, but they still work when you don't have that much bandwidth.

                                    > You're still pretending that it was fast even with text patches, e-mails or git.

                                    Exactly how much experience do you have on the internet at dial-up speeds? I was using dial-up from 1995 through 2005. Emails, whether they contained correspondence or patches simply did not take a noticable period of time to transfer.

                                    I'm not going to bother reading the rest of your response because you're just arguing for the sake of arguing.

                                    [1] https://tools.ietf.org/html/rfc5321#section-4.5.3.1.6

                                    • Avamander 1395 days ago
                                      > Which component is that? The SMTP protocol? According to [1], the maximum line length allowed by SMTP is 1000 octets, which is well over any maximum hard-wrapped line length for typical source code lines.

                                      The wetware component enforcing some line length - some old maintainer stuck in his ways. I don't see what you're trying to achieve ignoring that?

                                      > Hardwrapped text is only a problem for displays that cannot display lines as long as the hardwrapped line length

                                      You're incorrect, it's a problem on wider screens as well.

                                      > Mobile email clients are not suited for reviewing patches due to the fact that they typically use variable width fonts and do not provide a way to post replies inline with quoted text.

                                      Again, that's an issue caused by non-HTML e-mail that's currently enforced in way too many places. It's not a problem with any e-mail system that is even somewhat modern.

                                      > Why can't those tools work when I'm getting 5 to 10 kB per second downstream?

                                      That's not the issue, your network's QoS is bad.

                                      > Exactly how much experience do you have on the internet at dial-up speeds?

                                      Years, more than enough to know it was absolute shit.

                                      >> Nah, this reply is given to even insiders that don't want to deal with that obsolete shit.

                                      > Citation please.

                                      https://lkml.org/lkml/2020/5/28/1457

                                      Here. Linus shut him down nicely though. :)

                                      • u801e 1395 days ago
                                        > The wetware component enforcing some line length - some old maintainer stuck in his ways

                                        You need to be more specific about what you're referring to when you bring something up. I already stated that email clients can be set to use longer line lengths. Are you aware that the default line length for hard-wrapped emails is 72 characters, not 80? It shouldn't take 4 posts for you to be specific enough for one to get what you're referring to and then basically ignoring the point I already brought up pertaining to that issue.

                                        > You're incorrect, it's a problem on wider screens as well

                                        Given the level of nesting in this sub-thread, the large amount of blank screen space to the left of the post is not posing any issues in terms of readability. I'd rather avoid "embarrasing line wrap" due to hard wrapped lines that are too long for the display. Also, the format=flowed option has solved this issue.

                                        > Again, that's an issue caused by non-HTML e-mail

                                        I assume you're aware of the problems caused by HTML email where people end up getting phished because of the anchor element with the hfref property set to make the link look like a legitimate website like their bank? Email should be plain text only. Leave the HTML to the web browsers.

                                        > That's not the issue, your network's QoS is bad.

                                        If the QOS was bad, then email and IRC would not work. They still do on the slow downstream and upsstream connection. And even if your claim of QoS was true, that doesn't explain why I experience the same issue on my mobile with a GPRS connection.

              • ornornor 1399 days ago
                ?
      • Avamander 1398 days ago
        After reading that, I'm really thankful that git-by-email is dying. Hard wrapping is just really terrible for anyone not using a VT-100.
        • u801e 1397 days ago
          I'm pretty sure that most people would prefer their code hard-wrapped at a certain line length.
          • Avamander 1397 days ago
            That's a rather useless sentence if I'm being honest, most people would prefer their code bug-free as well.

            In the end, normal programmers don't write 1000char lines and do format their code nicely. Any limits should be soft, pedantic hard-wrapping at some arbitrary character count is just harmful.

            In the case of non-code, no, absolutely no hard wraps, people using phones, accessibility features or similar non VT-100 deserve readable text, not some disgustingly formatted column.

  • aimor 1399 days ago
    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 1399 days ago
      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 1399 days ago
        So just turn a 16:(9/10) monitor sideways. Plenty of vertical space.
        • bjoli 1398 days ago
          Two of them next to eachother makes for 16:18 which is my kind of screen!
  • spion 1399 days ago
    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...

  • hirundo 1399 days ago
    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 1399 days ago
    Isn’t there some merit to the notion that long lines are typically either overly verbose or mentally challenging to understand?
    • eeh 1399 days ago
      I think there's some merit to this, but it's a bit strict.

      Suppose I'm at 80 characters, and everyone agrees this is a reasonable line. Then suppose I refactor a variable that was 3 characters and its now 12 characters, and everyone agrees this is a better variable name. Now my 80 character line is 89, and it's suddenly unreadable?

      No, that's still readable, it's just longer.

      Personally if I see a long line, I try to shorten it, but I'm okay to leave it long if I think longer is better.

    • microtherion 1399 days ago
      Subjectively, I feel that at some width, I lose the ability to take in lines at a single glance, and spend more time in horizontal head movement. I rarely test this in code, but in web pages that use the entire width of the window, it's pretty evident to me that my reading speed goes down when the text gets too wide.

      Like Linus, I find 80 columns too narrow a limitation (and I got started on a 40x25 system, not even 80x25), but it would seem useful to me to standardize on some sensible maximum width, e.g. 100 or 120 columns.

    • kstrauser 1399 days ago
      In APL, sure (at least for me). In most common languages today, using meaningful variable names, it's pretty easy to have wide but readable lines.
    • colechristensen 1399 days ago
      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 1399 days ago
        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 1399 days ago
          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.

    • isoskeles 1399 days ago
      I think so, but it's still inconvenient when a length limit applies to something reasonable.

      Applying a short limit to solve the problem of any single line becoming overly-complex will have other consequences. Most obviously, it's going to push some developers into bad habits re: naming things, where variable names that have more meaning than a counter become single letters.

  • stickfigure 1399 days ago
    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 1399 days ago
      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.
      • stickfigure 1399 days ago
        It's readable, but not so good that people use it and stop fighting over line length and indentation rules.

        Four years ago I wrote a stackoverflow question about this and included some pictures:

        https://stackoverflow.com/questions/31414385/is-it-possible-...

        I got a link to a dusty now-9-year-old issue in Jetbrains' tracker:

        https://youtrack.jetbrains.com/issue/IDEABKL-6076

      • wallacoloo 1399 days ago
        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 1399 days ago
          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 1399 days ago
            > 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).

          • em-bee 1399 days ago
            didn't some variants of BASIC do this?

            smalltalk is storing the code together with the compiled result in an image, so it could do the same, but i am not aware of any implementation that does that.

    • gwillz 1399 days ago
      Perhaps this could be a new feature for the language server protocol? Or is it already in the works...?
  • wozer 1399 days ago
    I hate it when zealot coworkers reformat code to 80 columns. It almost always gets much less readable in the process.
    • rbanffy 1399 days ago
      God made the VT52 with 80 columns for a reason.
    • rantwasp 1399 days ago
      agree with them that there should be a limit and set it to 120
      • wozer 1399 days ago
        yes, 120 seems reasonable
  • camgunz 1399 days ago
    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 1399 days ago
      Why should online diffs auto format to 80 cols? Shouldn't that be up to the user?
      • camgunz 1399 days ago
        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 1399 days ago
    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 1399 days ago
      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 1399 days ago
    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/

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

    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 1399 days ago
      4 spaces allows you to have manual line wrapping, for example: if (a < b || b < c || ... || d < e || ... ) Do something.
  • vjeux 1399 days ago
    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 1399 days ago
      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.
    • pkilgore 1399 days ago
      > Word-wrapping is a property of the text. And the tool you use to visualize things cannot know. End result: you do word-wrapping at the only stage where you can do it, namely when writing it. Not when showing it.[1]

      - Linus Torvolds

      [1] https://github.com/torvalds/linux/pull/17#issuecomment-56611...

  • cdelsolar 1399 days ago
    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 1399 days ago
      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 1393 days ago
        my use case is extremely common.
  • 978e4721a 1398 days ago
    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 1398 days ago
      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.
    • makapuf 1398 days ago
      Books are definitely not indented, code can be up to 50% of actual text. In that case 120 columns.
  • wilg 1399 days ago
    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 1399 days ago
      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 1399 days ago
        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))
    • themodelplumber 1399 days ago
      In my experience, line wrapping makes line numbering uglier and less intuitively useful. This impacts line operations.

      I agree with Linus in some ways, but I think he's also repping a broad-front executive-style decision rather than a really nuanced one. And the details can really impact the preference in a case like this.

    • 0-_-0 1399 days ago
      I've recently been getting used to using line wrapping in VSCode (Alt+Z) and it's been working great. I only wish it was a bit more "semantic", similar to running a linter with a specified width rather than just copying the indentation of the previous line, so that e.g. when I need to wrap a line that's a comma separated list (e.g. function parameters) it lines up the list elements in 1 column:

          def f(
              a,
              b,
              c,
              d
          ):
      • Roboprog 1399 days ago
        I like it, but then I have adopted a style very similar to that in the last 3 or 4 years: format expressions to approximate their syntax tree, with closing symbols aligned with the line that opened the sub-tree. Essentially, K&R indentation for ALL grouping symbols, not just curly braces. This way, lines are never very long anyway. Well, especially since my JS code has more of a “Ruby, with a dash of Lisp” style than a “Java” style.
        • Roboprog 1399 days ago
          As to vertical size: how much crap are you going to put into one function, anyway? Other than perhaps some local (nested) helper functions.
    • catalogia 1399 days ago
      Editors support it fine, but personally I find the result aesthetically unpleasant no matter the editor.
  • jacobsenscott 1399 days ago
    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 1398 days ago
    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 1399 days ago
    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 1399 days ago
    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 1399 days ago
    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 1399 days ago
      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 1399 days ago
    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 1399 days ago
    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 1399 days ago
    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 1399 days ago
    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.

  • ceocoder 1399 days ago
    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

  • robomartin 1399 days ago
    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.

  • dkersten 1398 days ago
    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 1395 days ago
    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 1398 days ago
    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 1399 days ago
    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 1399 days ago
    A vt-100 could do 132 columns and I've always set my terminal windows to that width.
  • mD5pPxMcS6fVWKE 1399 days ago
    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 1399 days ago
    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 1399 days ago
    "Does Column Width of 80 Make Sense in 2018?":

    * https://news.ycombinator.com/item?id=17436945

  • zajio1am 1399 days ago
    Personally, i limit line length to 95 columns - 1920 / 10px wide font / 2 (horizontal split screen) is 96, minus some pixels for borders.
  • lmilcin 1398 days ago
    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.

  • alkonaut 1399 days ago
    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?

  • pauljurczak 1399 days ago
    We had only at most 72 positions available on 80 column punch cards, and we loved it! Bring back the 1950s! ;-)
  • nickdothutton 1399 days ago
    Old enough to remember 132 column line printers and using them to do code reviews. It felt very convenient.
  • jofer 1399 days ago
    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 1398 days ago
    I keep my VT420 in 132x39 mode, but it does take a little longer to redraw the screen at that size.
  • ridiculous_fish 1399 days ago
    Text has solved this problem without requiring hard line breaks at regular intervals.
  • SparkyMcUnicorn 1399 days ago
    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 1399 days ago
    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 1399 days ago
    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 1399 days ago
      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).
      • ken 1399 days ago
        Up to 79 characters, including the line number.

        Interestingly, this was basically (ha) an editor limitation, not a language one. You could use 2-letter abbreviations for the language's reserved words to cram more code into the same space. The programs were stored (IIRC) in tokenized form.

      • winrid 1399 days ago
        The more you know! Thanks.
        • saalweachter 1399 days ago
          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.
    • krallja 1399 days ago
      80 columns on a C64 is a real reach. You need special hardware (or horribly slow & fuzzy text) for that.
  • madhadron 1399 days ago
    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 1398 days ago
    That email sure seems to be formatted for 80 columns
  • jftuga 1399 days ago
    I guess his new AMD CPUs can now handle the wider columns!

    :-)

  • jedisct1 1399 days ago
    I like 128 because it’s a round number.
  • briandilley 1399 days ago
    I wonder how Linus feels about tabs vs. spaces (I didn't read the entire post, so maybe he addressed it?)
    • mariocesar 1399 days ago
      > And yes, we do use wide tabs, because that makes indentation something you can visually see in the structure at a glance and on a whole-function basis, rather than something you have to try to visually "line up" things for or count spaces.

      That is what he says

    • billsnow 1399 days ago
      In the post he refers to "wide tabs" which means hard tabs displayed 8 chars long. This has been the standard kernel style since the beginning.
    • saagarjha 1399 days ago
      The kernel uses 8-space tabs.
      • ccmcarey 1399 days ago
        How do you mean 8 space tabs? Are tabs not single characters \t?
        • ordu 1399 days ago
          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 1399 days ago
            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 1399 days ago
              >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 1399 days ago
                > 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 1399 days ago
    I really like this wiser version of Linus. Imagine that text five years ago)
  • imglorp 1399 days ago
    Good riddance. If we pick a new suggested width, maybe it shouldn't be based on a 1928 punch card standard.
  • CalChris 1399 days ago
    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

    • truncate 1399 days ago
      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`.