1. 75
  1.  

  2. 42

    I’ve always felt the whole “terminal size” thing is a massive irrelevant distraction; I wrap lines (usually at 80) because I think shorter lines are easier to read.

    Obsessively wrapping at 80 (or any other limit) is not helpful though; 90 or 100 can be fine too; the important question is “is it easier to read?” and often – but far from always – I find a length of 80 “easier to read”.

    People/tools that are obsessive about “80” are annoying as it forces unnatural weird line-breaks and make things harder to read, and that’s basically the issue at hand here; the change that prompted this discussion:

    -ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos)
    +ssize_t __kernel_write(struct file *file, const void *buf, size_t count,
    +               loff_t *pos)
    

    The original line was 85 characters, and it makes little sense to break there IMO.

    1. 14

      The TeX papers cited a study that showed that humans read best (on average) when lines are 66 non-whitespace characters. That actually corresponds pretty well to an 80-column terminal (14 words, average word length 4-5, a bit longer if you have leading whitespace for indentation). I wrote a style guide a long time ago that included that as the rule: lines should not be longer than 66 non-whitespace characters unless breaking them would harm readability.

      The get-out clause is important, because sometimes you really can’t usefully make them shorter, but often you can. The non-whitespace rule is important because it avoids one of the problems the Linux kernel has: they define their tab width to be 8 characters and so any line in a function has only 72 characters to play with and one inside an if block has only 64, which is a tighter restriction than you need for readability.

      1. 20

        I assume that study was about prose rather than code though. Code is fundamentally different: more punctuation, fewer “words”, and heavy use of indentation that shrinks the line count for the majority of lines in any codebase.

        I wouldn’t expect a study tested on prose to completely generalize to code. As a hypothesis, I would suspect that people tend to skim through code looking at the “shape” of the text: looking at indentation, statements, balancing parentheses, etc. Lines that are too short means more cases where that shape is modified due to wrapping, hampering readability.

        1. 5

          I don’t know if anyone has done the study for code, but I have recently been surprised by some that show that they are more similar than I would have thought. For example, most of us know that syntax highlighting makes it easier to read code. There was a study that I read a couple of years ago for English text that applied part-of-speech tagging and then highlighted words based on this (so nouns, verbs, and so on were coloured differently). They found either an increased retention rate when reading at the same speed or an increased reading speed for the same retention rate.

          I’d be really interested in seeing a study on comprehension related to line length for code, especially compared across languages (any HCI folks looking for a grant idea?). I’m also not sure how generalisable the originals studies were to across Latin-alphabet languages and I’d be curious if the difference between English and Python is more or less pronounced than the difference between English and German or C and Python.

        2. 1

          The TeX papers cited a study that showed that humans read best (on average) when lines are 66 non-whitespace characters.

          What TeX papers are you referring to here?

          1. 2

            Knuth and the PhD students that he had working on TeX published a load of papers about how and why the system works. They’re a great resource for anyone interested in typesetting because they describe the algorithms they implemented, the algorithms they wanted to implement but couldn’t because of resource constraints, and the rationale for picking those algorithms.

            The paper describing the hyphenation algorithm, for example, describes a technique that MIT is now making a big fuss about where you train a simple ML model (in their case, as I recall, a two-deep Markov chain) and then record the instances where it makes the wrong prediction. For English, the entire hyphenation dictionary is the single model + about 70 outliers. It’s both small and very fast to search.

        3. 12

          One reason for “strong feelings” (for the lack of a better word) is multiple buffers open side-by-side in vim for example. I often tend to have 2 buffers open split screen in vim, one with the source file and the other one with the test. Shorter lines make it much easier to support this workflow.

          1. 1

            Can you have no more than a width of 160 characters comfortably displayed on your monitor?

            1. 9

              With my current hardware that number is about 180-200 (leaving out the space that the file browser plugin takes up on the left).

              Any more characters and I would have to decrease the font size to still be able to work with split buffers. But I’ve noticed that I feel strain in my eyes when the font size is too low.

              1. 1

                If you close the file browser, and have two files side by side, does the file length really have to be limited to 80 for the font size to be comfortably large to read? I find this hard to belive unless you have an unusually small monitor.

                1. 4

                  With the file browser disabled, each buffer can accommodate about 115 characters at font size 12 (~110 to still have some spacing for comfortable reading). While that’s certainly more than 80, I feel my personal upper limit would be 90-ish. More than that I think I would have to either change my workflow or invest in a new display.

                  Also, yes my hardware might qualify as being slightly dated. The laptop I use has a max resolution of 1920x1080. I do have an external display but that’s even older than the laptop and only supports 1440x900. ¯\_(ツ)_/¯

                  1. 1

                    That makes sense. I vote for 90 being the new default maximum line length, then. ;)

          2. 10

            I agree in spirit, but in practice many people lack common sense. Subjective criteria alone are not enough.

            1. 4

              Besides the common sense issue, some people appreciate hard formal restrictions for their creations. For example, that’s the whole point of poetry: to write stuff according to arbitrary rules that are orthogonal to the meaning. A sonnet has 14 lines of 10 syllables, just as linux kernel code has indentations of width 8 and a maximum of 80 columns per line.

              1. 6

                I would find it hard to argue that arbitrarily limiting the length of a line of code makes it any more “poetic”, in some way?

                More to the point, much as we like to compare code and poetry, real-world concerns impose. Sometimes it’s preferable to do the less poetic/more verbose thing in the name of keeping your code maintainable and (hopefully by extension) working in the future, for example.

                1. 4

                  I think what GP is getting at is that (for many people, anyway) one of the top killers of creativity is, ironically, the blank canvas. The total freedom. One of the most common tips for getting around creative blockage is imposing arbitrary constraints.

                  Not saying software engineering is 100% creativity, but at least a part of it is?

                  1. 4

                    Yes, that was exactly my point. I have found that artificially adhering to 80 chars per line and 8-width tabs forces me to code in a very productive way (and especially, that functions have at most 30 or 40 lines). Sure, I have to rewrite and refactor the code quite a few times until it reaches that state, but I do not feel like I’m losing my time, quite the contrary.

                2. 2

                  Quite the opposite, rules such as the sonnet format are anything but arbitrary. They exist so the message can be delivered in a specific poetic fashion. They allow for a singer or a poetry reader to resource to a certain set of vocal/techniques techniques.

                  It might sound counter intuitive, but meaning of a particular sonnet is not easily transferable to other formats. Much like the meaning of a ballad would hardly had the same strength if passed as an heavy metal song.

                  I do not think there is an equally strong point at all when it comes to people wanting hard formal restrictions in their code because they like it. Engineering should be more pragmatic than this. If there are valid reasons, such as screen real estate in old days, that’s ok. But reasons without practical motivation become an unnecessary annoyance in my experience.

                  1. 2

                    Quite the opposite, rules such as the sonnet format are anything but arbitrary.

                    I have the exact opposite view on the nature of poetry (not that there’s anything wrong with that). While the origins of poetic forms may have something to do with singing, this is not what the poetic thing is about. For example, when writing the lyrics of a song you may need to add an extra syllable on one of your lines and this will not matter: the singer will simply pronounce the two syllables faster, it happens all the time. However, if you add a single spurious syllable in a sonnet or a haiku, then the whole thing falls apart and ceases to be a sonnet or a haiku.

                    If you read modern poetry (i.e., not influenced by any musical form that motivated it) you’ll find that the best poems can be also read as perfect prose, and the strict formal properties (rhythm, rhyme) just fall casually into place.

              2. 2

                I wrap to 80 characters almost always when creating a patch, just so there’s one less thing for people to complain about. However, I think wrappings like the above are a particularly egregious failure case. Sometimes adding or modifying a single argument can necessitate a second line…

              3. 51

                I think this is a good example of how Linus can strongly and bluntly call out things he thinks are dumb without calling anyone braindamaged or saying people should be retroactively aborted.

                1. [Comment removed by author]

                  1. 47

                    Did they drug him? Do they rewrite their texts before allowing him to post? We want the real Linus back!

                    What the fuck. Are so you opposed to people changing their behaviour for good reasons that you’d rather believe in a cabal that controls Linus?

                    1. 2

                      But there is such a cabal. Linux is under immense corporate pressure. It’d be naive to think The Linux Foundation had nothing to do with Linus’s “change of heart”.

                      1. 1

                        Eh, it’s natural. I don’t think Linus is unhappy that he has so many full-time people at places like Intel working tirelessly on the kernel. So maybe providing a place where their bosses don’t feel conflicted isn’t a terrible thing.

                2. 19

                  I do really like Linus’ point earlier in the thread too: “checkpatch” throws a warning about 80 characters… while generating 124 character lines.

                  1. 15

                    No, source code these days isn’t “fundamentally wider”. Keeping things simple is still an advantage. Think about the amount of nesting which can go on beyond 80 columns. We don’t need more spaghetti in the kernel.

                    1. 5

                      I really feel current best practice leads to wider code: we use longer variable names, longer parameter names and longer function names.

                      We mostly stopped using goto and rely on blocks for flow control and often we pass closures to other functions, causing further indentation.

                    2. 14

                      Here’s the thing: I submit that the more important unit is the semantic chunk (“code morpheme”?), rather than the character, and it’s the former that we should be watching for excess of per line. As I tell people: I think code is more readable when it’s more vertical than horizontal. I almost always try to string code morpheme sequences line by line, rather than side by side.

                      Some pseudocode examples to illustrate:

                      # Instead of this:
                      some_method(some_arg: some_value, another_arg: another_value, arg3: val3)
                      
                      # I'd write this:
                      some_method(
                        some_arg: some_value,
                        another_arg: another_value,
                        arg3: val3,
                      )
                      
                      # Instead of this:
                      some_object.chained_method1(arg).chained_method2(arg2, arg3).chained_method4
                      
                      # I'd write this:
                      some_object
                      .chained_method1(arg)
                      .chained_method2(arg2, arg3)
                      .chained_method4
                      
                      # Instead of this:
                      if (comparable > some_threshold || something.in?(some_array)) && obj.is_foo?
                        do_something
                      end
                      
                      # I'd write this:
                      if (
                        comparable > some_threshold ||
                        something.in?(some_array)
                      ) && obj.is_foo?
                        do_something
                      end
                      

                      Very few morphemes per line, and almost always combining on one line things that themselves make up one group (rather than more than one group). What the reader enjoys from this style is that they don’t have to visually trace the morphemes (or groups) both horizontally and vertically; they only encounter the semantic entities in one direction, along one path. I think this makes the code easier to understand and reason about.

                      So, as regards “line length linting”: when you write according to the above guideline, your lines tend to be shorter than 100 characters.

                      1. 5

                        This is the convention favored by tools like black as well, and I find my quality of life has improved since I embraced them. Even though philosophically I am “fine” with 120-width lines, I haven’t found that this leads to very many “what?!” formatting outcomes – and if it does I can often refactor to a local variable instead. For example, in the if block above I might add a local:

                        foo_is_relevant = comparable > some_threshold || something.in?(some_array)
                        
                        if foo_is_relevant && obj.is_foo?
                          do_something
                        end
                        
                        1. 2

                          Yep, Extract Variable is a good tool to have in your developer’s toolbox.

                          Black makes code review faster by producing the smallest diffs possible.

                          Another benefit of more-vertical code. (Though I cede that it’s not too hard to get diffing tools to ignore whitespace and highlight mid-line changes.)

                      2. 21

                        Yeah, 72 is much more reasonable. We need hard limits, or at least ‘annnoying’ conventions to keep the horrors at bay. The human eye scans lines best at around 72 characters wide, and we should put human readability of our code before other concerns. I have worked on projects that had huge long lines and there is no excuse. If a language or tool or whatever can’t deal with human limits, find or make another tool. Linus’ current workstation should not be the standard.

                        That being said, I think Racket has made a reasonable compromise:

                        A line in a Racket file is at most 102 characters wide.

                        If you prefer a narrower width than 102, and if you stick to this width “religiously,” add a note to the top of the file—right below the purpose statement—that nobody should violate your file-local rule.

                        This number is a compromise. People used to recommend a line width of 80 or 72 column. The number is a historical artifact. It is also a good number for several different reasons: printing code in text mode, displaying code at reasonable font sizes, comparing several different pieces of code on a monitor, and possibly more. So age doesn’t make it incorrect. We regularly read code on monitors that accommodate close to 250 columns, and on occasion, our monitors are even wider. It is time to allow for somewhat more width in exchange for meaningful identifiers.

                        https://docs.racket-lang.org/style/Textual_Matters.html

                        1. 25

                          The human eye scans lines best at around 72 characters wide

                          I would like to have 72 chars wide line but with ignored indentation. It would make nested block readable on its own.

                          Example with 40 chars width ignoring indentation white space

                          Lorem ipsum dolor sit amet, consectetur
                          adipiscing elit. Donec sit amet augue
                          felis. Suspendisse a ipsum et sem auctor
                          porttitor in ac lacus. 
                          
                              Curabitur condimentum augue diam, ut
                              molestie nibh faucibus nec. Aliquam
                              lacinia volutpat tellus, non
                              sollicitudin nulla luctus sit amet.
                          
                                  Aenean consequat ipsum sem, ac rutrum
                                  leo dictum at. Suspendisse purus dolor,
                                  condimentum in ultrices vel, egestas vel
                                  ipsum.
                          

                          Versus 40 chars width including indentation

                          Lorem ipsum dolor sit amet, consectetur
                          adipiscing elit. Donec sit amet augue
                          felis. Suspendisse a ipsum et sem auctor
                          porttitor in ac lacus. 
                          
                              Curabitur condimentum augue diam, ut
                              molestie nibh faucibus nec. Aliquam
                              lacinia volutpat tellus, non
                              sollicitudin nulla luctus sit amet.
                          
                                  Aenean consequat ipsum sem, ac
                                  rutrum leo dictum at.
                                  Suspendisse purus dolor,
                                  condimentum in ultrices vel,
                                  egestas vel ipsum.
                          
                          1. 18

                            The human eye scans lines best at around 72 characters wide

                            With monospace fonts? Or proportional ones? With large text or small?

                            With English prose, poetry, or with C code? With hyphenation? Indentation?

                            I’ve found that recommendation is pretty good for English text with a middle size proportional font. I do not find it works as well for code.

                            1. 5

                              100% agreed. As I argued in the comments above, people don’t read code the same way that they read prose, and so I would not try to generalize a heuristic meant for prose to code.

                              1. 3

                                I agree. Reading written text involves repeatedly shifting your focus to the line below. A consistent and short line length in that case is very important. Code is not the same. It’s far more common reading code to study a single line or small block, and in that case, I find that arbitrarily wrapping a line to stay within 80 characters usually breaks consistency and harms readability. I used to subscribe to the 80 character limit until I realised this difference. We don’t read code like we read written text.

                                Terminal/editor windows side by side is a fine point, but in general the vast majority of lines of code are short anyway, often well under 80 characters. If a few lines happen to wrap on your display, I hardly think that’s going to completely kill readability, and it’s certainly a trade-off I’m willing to make. If many lines are wrapping then yes, you probably have a problem with your code formatting (or your code in general). It’s the hard limit that I take issue with. Back when I wrote my own code like this, all too often I would find myself renaming identifiers (usually for the worse) among other arbitrary and unhelpful things, just to fit some code within a line without wrapping. I wouldn’t be surprised if more often than not this is the outcome for many others who attempt this, and it’s almost certainly a net negative for readability. Dropping the idea entirely has been a huge relief. One less thing to think about. Most of my code still consists of short lines, as it always did, and as most code naturally does. But when I need to, and it makes sense to write a longer line, I don’t spend a second agonising over whether it fits within some special number of characters, and instead focus entirely on whether it in itself is clear and understandable.

                              2. 10

                                I want to reinforce your comment that

                                The human eye scans lines best at around 72 characters wide, and we should put human readability of our code before other concerns.

                                Recently, I have been trying to optimise my on-screen experience and I found a series of peer-reviewed articles with recommendations that improved my experience.

                                In one of those, it is claimed, indeed, that more than 72 and less than 80 characters (precisely, 77) is the optimal number for clear readability.

                                The study is for dyslexic people, and I was never diagnosed as so. But it works for me, and I tend to believe it works for most people as well.

                                1. 1

                                  Yeah what I’ve read confirms this, I think the width of the text column can vary based on the character width. For example in CSS I typically set something like:

                                   p { max-width: 32em; }
                                  
                                  1. 4

                                    You can also use 72ch to set it based on width of the 0 character (which will approximate it)

                              3. 9

                                I’ve been formatting everything to 120 for a decade. It’s enough to relieve the cramp that 80 columns imposes, and avoid most unnecessary linebreaks, but it’s also not so wide as to impair readability by making it hard for the eye to find the next row. And absolutely nobody has complained. I think you could probably even take it a little bit higher, but IMO 120 is fine.

                                1. 12

                                  Lots of us still use 80-column terminals every day, but sometimes Linus’ arguments are just “I don’t like it so it’s bad”. This is one of those times.

                                  Furthermore, his argument essentially boils down to “my monitor is big and my eyes are still functional so fuck you if yours aren’t”.

                                  1. 6

                                    no, the argument is “we use longer variable names and function names, as well as large indenting, which is more important for readability than 80 chars” … and isn’t it in fact hard to find screens on the market that physically limit to 80?

                                    1. 1

                                      Not everyone wants their code up full-screen. Most of my screen goes to a web browser with an 80-width terminal next to it so that I can see the results live-reload in real-time.

                                      1. 1

                                        then I hope you’re not using Java.

                                        It all depends on the language you’re using. I’ve used some where 80 is completely fine. And sometimes you kinda need 100 to not get an unreadable mess.

                                        1. 1

                                          I’m not that kind of masochist, no.

                                    2. 6

                                      Furthermore, his argument essentially boils down to “my monitor is big and my eyes are still functional so fuck you if yours aren’t”.

                                      Exactly. As I said in my other comment, why should people who have these conveniences get even more, at the expense of people who have less?

                                      1. 2

                                        By choice or by necessity?

                                        I doubt there are really many out there, whose equipment literally can’t display more than 80 columns. Maybe you are one of the few.

                                        If by choice, then you are really just arguing that your personal preference on how to work is more valid or important than Linus’.

                                        I generally aim for 80 chars myself, because I’m old enough that this is a habit, but prefer to use tools like black to avoid even thinking about it.

                                        1. 1

                                          Even when I only have one window up, I still keep a thin window by choice Longer lines cause eye strain over longer periods of time. This is similar to how most well-designed news and other content oriented sites are designed to show somewhere around 76 characters per line.

                                          For instance, look at Twitter in full-screen. There is a maximum width of a tweet… At least until their designers ruin that like the rest of their recent UX changes.

                                      2. 7

                                        I clang-format and focus on programming.

                                        1. 6

                                          Here’s an interesting anecdote from my work:

                                          We’re using 80-columns as limit for all code, not because of choice or history – but because we have a programmer with limited eyesight who has to have text so large, despite a 21:9 34” screen, only 80 characters fit on one line for him.

                                          Accessibility is an issue I personally never thought about before when discussing column limits, so I wanted to mention this interesting anecdote :)

                                          1. 2

                                            Wow! If I may ask, how long has he been with you guys?

                                          2. 5

                                            I really hope the “Git commit message length 50/72” rule also get revised, as some editors, vim for example, keeps breaking my lines when committing from the command line.

                                            1. 11

                                              I’ve often not respected the “50-line summary” and I think it’s made for better commit messages. Without being excessive, 60-70 characters can give you some wiggle room to be more precise.

                                              1. 0

                                                I have total disregard for this “rule” (except for projects where there is a hard policy, of course. For public PRs, eg. github, the project owner will create the final commit message anyway).

                                                A short single sentence overview of the commit must for. Also automatically added stuff must fit (eg. Merge PR12345). If it is 200 characters, who cares? Usually it will be displayed on an ultrawide monitor in a web browser. Also my terminals are able to line wrap. At least history can be grepped/searched properly

                                                Note: I prefer to work in squash-merge-by-default workflows which I think create the need for a bit longer commit messages, as commits a usually a bit bigger complete feature level closed entites.

                                                1. 9

                                                  I think there’s some good reasons for keeping short summaries though: it’s like the Subject: field of your email: a concise description of what it’s about. It makes things like git log much easier to read IMO. Having terminals line-wrap all of that makes stuff much harder to read.

                                                  Another (more pragmatical) reason is that some tools don’t like long commit summaries. Specifically, GitHub doesn’t show it very well.

                                                  I think 50 is a good rule-of-thumb, which can be broken occasionally when it makes sense.

                                                  1. 2

                                                    I don’t mean to write the complete changelog in one line, but if it gets longer, then it is longer. It must be legible text, momentary presentation trends/limitations don’t matter so much, as Github theme, terminal size, etc. changes, but the commit stays there, and must be quickly understandable maybe years later.

                                                    1. 5

                                                      200 characters doesn’t strike me as “quickly understandable” though; that’s a long sentence instead of a concise summary. I can’t really think of any situation where that can’t be shorter?

                                                      1. 1

                                                        It was just a number from the top of my head, to illusttate the magnitude of my not caring for the convention, not result from exact resarch of my project histories.

                                                        Also when doing releases/deploys I preferred to have extensive “top leves description” of changes of my “underlings” when reviewing hundreds of commits since last release, to be able to recap the extent and risks of the changes.

                                                        Having PR 54321: ComponentX: Framework update to x.y.z. Fixes BUG-12345. WARNING: Config format changed! WARNING: SSL 1.0 support dropped! WARNING: Requires OS update level ZZZZ

                                                        Instead of PR 54321: ComponentX: Framework update to x.y.z. totally made sense becuse in operations several OS versions were in use at OPS, several teams were working on the code (monorepo), and ops people could instantly get info from oneliner changelogs about the risks of updates.

                                                        Monorepo, squash merge, and this potentially long commit summary convention improved the workflow in our situation, and overall the quality of our service. Adhering to arbitrary line length rules because “some guy uses tiny terminal windows and does stuff in the console that we do other way” would have beared no fruit for our customers.

                                                        The commit messages had other lines detailing these changes, to let ops team know where the docs are, what are the other implications, etc.

                                            2. 5

                                              I feel like I’m entering full-paparazzi mode, while ignoring the point being discussed, but does

                                              That’s with my default “100x50” terminal window (go to your gnome terminal settings, you’ll find that the 80x25 thing is just an initial default that you can change)

                                              Imply Linus uses GNOME? I’m kind of embarrassed to ask this, but on the other hand the discussion is how long lines can be.

                                              A sentence that bothers me is

                                              People with restrictive hardware shouldn’t make it more inconvenient for people who have better resources.

                                              because that could be taken further to say we aren’t interested in supporting older or lower end devices. It’s not that probable as long as Linux is used in the embedded domain, but that would be a development that I would be weary of.

                                              1. 8

                                                Everyone seems to be fighting about the concrete width but nobody mentions it actually depends on the language. It’s easy to write 80-character wide Python, it’s much harder in Java. (Most Python code I saw that insisted on 100+ character limit was written in Java style).

                                                1. 10

                                                  I’m with Linus. 80-character limits one the 21st century are an anachronism. The legibility studies being mentioned here are about people reading natural-language prose, in long paragraphs that wrap. The shorter line length helps the eye Jump accurately from the right margin to the start of the next line.

                                                  Code isn’t read that way, in any language I know of. It’s short individual lines, with no consistent length, and in most languages they’re indented to varying levels. We scan it in all different ways depending on what we’re doing — I bet someone’s done eye tracking studies, but thinking about myself, a lot of the time I’m skimming the start of each line looking at the statement keywords (if, for, let, return…) and indentation. Or I’m looking at all the instances of one variable name that my editor’s highlighted for me.

                                                  Consider also that the real meat of the code, the function bodies, is usually indented, which eats away at the line limit. In C++ I’m usually inside a method in a class declaration in a namespace … that’s 12 spaces subtracted from the line width. I go into an if or `for, another 4 gone. That’s 40% of an 80-char line lost before I start typing anything! (I know some people use 2-space indents to work around this. I find that’s too narrow for me to ‘read’ indentation accurately.)

                                                  1. 3

                                                    And I get the feeling also that many languages that use 2 character indent by convention, do so in order to keep lines within these limits. I also find 2 spaces borderline too narrow, despite using it in Ruby code daily (where it is so standard that you’re really better off just going with convention for the sake of the community).

                                                  2. 4

                                                    I think the “line-based tools” argument can work both ways. If a single line encompasses multiple “code chunks”, as in u/Pistos example:

                                                    some_object.chained_method1(arg).chained_method2(arg2, arg3).chained_method4();
                                                    
                                                    • I can’t use vim’s line-based commands to copy/delete a single chunk
                                                    • If I replace chained_method2 with chained_method3, a line-based diff (most of them) will just show a change to the whole line.

                                                    Whereas if it’s spread out:

                                                    some_object
                                                        .chained_method1(arg)
                                                        .chained_method2(arg2, arg3)
                                                        .chained_method4();
                                                    
                                                    • line-based editing makes it easy to copy/paste/move code chunks
                                                    • line-based diffs will just show the chunk that changed (and consequently won’t conflict if e.g. someone changed chained_method4 while I was changing chained_method2).

                                                    Personally, I’m in u/tclu’s “short lines are easier for humans to read” camp, so do short lines except when necessary.

                                                    I think programming languages and frameworks can have a huge impact on whether shorter lines are comfortable to write. For example, good namespacing/scope means that you don’t have to prefix every function and variable name with its scope.

                                                    1. 4

                                                      Its funny that this email is formatted to 71 columns.

                                                      1. 2

                                                        What’s funny about it? It’s written text, not code, they are not comparable beyond a superficial level.

                                                      2. 5

                                                        The irony of that entire rant being wrapped at 70 characters is just killing me.

                                                        1. 1

                                                          English is not code.

                                                          1. 5

                                                            I understand that. I run a publishing company and write typesetting software (see SILE). And I agree, prose and code have different requirements. Long lines in code make sense in some cases and some languages. I tend to still prefer shorter lines particularly when the language in question facilitates short expressions, but think enforcing a hard wrap makes code unnecessarily messy in some cases.

                                                            It was just the irony that got me.

                                                        2. 3

                                                          80, 100, or 120 character limit; I don’t mind, and do what the team’s standards are for writing code.

                                                          What I do mind is a linter with no manual override forcing my 81 or 101 or 121 character line into multiple to enforce some arbitrary limit.

                                                          1. 3

                                                            In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake.

                                                            I wish “bait” was a flag option.

                                                            1. 4

                                                              People with restrictive hardware shouldn’t make it more inconvenient for people who have better resources.

                                                              This seems fundamentally backwards to me. People with better resources are already privileged. Why should they have even more convenience, at the expense of people who have less?

                                                              1. 6

                                                                Because in context, run-of-the-mill hardware has supported much larger screens and computing capabilities for quite a while now.

                                                                But no, 80-column terminals in 2020 isn’t “reasonable” any more as far as I’m concerned. People commonly used 132-column terminals even back in the 80’s, for chrissake, don’t try to make 80 columns some immovable standard.

                                                                Wide screens and a minimum of 1280 pixels by 720 pixels have been the standard for nearly a decade by now. Eighty columns is more of a ballpark. Like in typography, too long of lines will be hard to read and too thin of lines or too many haphazard newlines wear you out reading vertically. In other cases, it does make better sense to accommodate less-capable hardware.

                                                                1. 4

                                                                  Your argument proves too much. According to that reasoning, video games should come configured to use one-handed controls by default, because there are some one-handed video game players. If you’re one of those privileged two-handed people who want the luxury of being able to walk and turn at the same time, you can go to the Options menu and turn on two-handed controls.

                                                                  Of course, making two-handed controls the default makes sense. The reasoning is simple: (number of two-handed players) × (magnitude of their benefit from not having to go to Options) > (number of one-handed players) × (magnitude of their harm from having to go to Options).

                                                                  In general, you can’t answer a question about privileged vs. unprivileged just by choosing to always favor the unprivileged. You have to compare the number of people affected on each side and the magnitude of those effects.

                                                                  Linus’s argument didn’t come with numbers, but when he wrote “yes, we’ll accommodate things to within reasonable limits”, I think the above type of calculation is the meaning of “reasonable” he was getting at. Of course, if your estimates of the numbers showed that longer lines of code are not “reasonable” in this sense, that would be a valid argument.

                                                                2. 2

                                                                  Sounds like the Linux style guide needs updating.

                                                                  1. 1

                                                                    Not sure what you’re referring to. I don’t expect the style guide to be 100% in line with Linus’s opinion, since that’s whimsy whereas the guide is a compromise. But this seems more or less compatible:

                                                                    Statements longer than 80 columns will be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information.

                                                                    1. 2

                                                                      Here’s Linus pointing out that the style guide needs updating: https://lkml.org/lkml/2020/5/28/1245

                                                                      If 80 columns isn’t reasonable anymore, then there’s no reason to mention 80 columns in the style guide.

                                                                  2. 2

                                                                    80-column anecdote that isn’t about writing code.

                                                                    A few years ago I played a lot of NetHack, which is a ncurses terminal game. On popular game servers that run dgamelaunch you can watch others play NetHack on their terminal, on your terminal. Back then, most people played with the default 80x24 or 80x25, and were watchable. (Obviously you can’t watch games being played on a terminal larger than yours – you’ll have to resize.)

                                                                    Today if you log in to NAO, you’ll see at least half of the players sporting various larger terminal sizes. Heck, the first 5 right now are 212x52, 208x50, 120x30, 113x25, 194x47. So the 80x25 norm definitely existed way into the 2010s, but the transition we’re seeing? It had to be sometime in the last 5 years.

                                                                    1. 1

                                                                      Obviously you can’t watch games being played on a terminal larger than yours – you’ll have to resize

                                                                      huh? Is everyone playing on the curses interface? The basic nethack UI is still 80 column, so no matter what someone’s terminal size is, wouldn’t the watch thing just crop the blank space around it?

                                                                      1. 1

                                                                        That’d be nice! Though for some reason the behavior has always been to wrap rather than crop, so they’re still a mess without a larger terminal size.

                                                                    2. 2

                                                                      I’d like this rule to be expanded to writing e-mails. If the 80-column line limit doesn’t make sense in source code (I partly agree; 80 limit is small, but 120 seems appropriate), then why on earth people think that e-mails should be hard wrapped to 80 characters? Nobody else is using hard wraps when communicating, only e-mail uses it.

                                                                      1. 6

                                                                        I find a consistent column of text easier to read than sentences that span the entirety of my monitor.

                                                                        1. 6

                                                                          That’s something that can easily be fixed in your email client by enforcing a maximum width on the reading pane, e.g. max-width: 50em in CSS, or in terminals just insert newlines every 50 characters.

                                                                          The problem with hard-wrap is that it will look bad for everyone with smaller screen, which is actually pretty common and not something that can easily be fixed since you can’t tell the difference between a “soft wrap” and “intended hard wrap”. I actually wrote a thing about this a few weeks ago: https://www.arp242.net/email-wrapping.html

                                                                          Unfortunately quite a few email clients don’t display this very good, but that’s an almost trivial fix. Certainly easier than telling millions of people that “you’re using email wrong”.

                                                                          1. 2

                                                                            So set up soft wrapping in your email client then. You will then have what you like, and others will have what they like.

                                                                          2. 5

                                                                            I don’t understand this either. I recently joined a mailing list where the predominant formatting is 80-character hard wraps. As a newcomer I emulated them (when in Rome etc.) but it would make far more sense if everybody wrapped their own lines to what is comfortable. It’s prose text after all.

                                                                            When somebody complains about an unstyled HTML page being too wide on their monitor, others dutifully point them to reader mode. But email is different for some reason. (Why user agents don’t take more creative licence when given a bare HTML document baffles me but is verging off-topic…)

                                                                            1. 2

                                                                              No, only some communities demand their members to use email this way. If not 72 columns… :S