80 characters happens to be just a little longer than the supposedly ideal measure for continuous text promulgated by Robert Bringhurst.[2]

I take the even more draconian approach of wrapping to 72 columns when writing comments, after the fashion of PEP 8.[3]

Of course, Linus will dictate the style of his projects' codebases as he deems fit.

[1]https://en.wikipedia.org/wiki/Saccade

[2]http://webtypography.net/2.1.2

[3]https://www.python.org/dev/peps/pep-0008/#maximum-line-lengt...

- Most lines are short even if the limit is more than 80 characters, so you're unlikely to accidentally shift up or down after reading a long line.

- Even if there turns out to be some benefit for reading code based on Saccades, that means nothing unless you can make some quantitative comparison with the other advantages and disadvantages of a longer line length.

80 charcters starting at the point of indentation is more reasonable. At two levels of indenting, you might get out to 96 characters, which still fits comfortably in most GUI terminal windows.

When reading code, I'd rather see a single statement on one line, rather that break it at 2 lines because it passed some ancient 80 char limit...

I don't care if a line needs to be 180 chars if it starts with log.debug. Just like searching, I read my code globally based on the first 10-20 chars. If I need details on a line, I'll read the whole line.

I do however put chained methods on new lines, because they are often a new statement.

And I use 4 spaces for indent, because my IDE is smart enough, it is in my programming language guidelines, and that's what my comapny uses.

So can simple arithmetic that would be worse with intermediate values.

No, but it means we better use rubber wheels, not stone ones...

Oh wait, we use wheels sized for their use cases…

http://www.naciente.com/essay94.htm

PEP8 is strongly biased towards making code readable, and has helped a generation of programmers start thinking about readability when coding. The line length limit, though, is one of the few parts of PEP8 that introduced defects as a practice. Holding to 80 characters causes:

* string concatenation bugs from breaking up long strings

* errors in expressions broken up into multiple expressions just to fit

* bias to use shorter variable names

My favorite part of PEP8 was the warning about "foolish consistency".

Which also happens to be how Linus wrapped the lines of this particular email.

Some arguments in favour of longer lines would be:

- monospaced fonts are relatively wide so the line is not long in terms of the number of characters

- there can be a lot of non-length on the left hand side due to indentation (especially in Linux where tabs are wide)

- programmers are relatively literate and so might perform better than average at finding the start of the line

- editor features like line highlighting can help to find the line

- source code has a very ragged edge and so it is easier to find the start of the line than in dense prose.

- magazines or their readers prefer narrow columns for stylistic reasons. E.g. newspapers sometimes have very narrow columns that lead to intraword spacing that makes things hard to read

2) The 80 or 66 char or whatever is literally a non-science driven designer rule of thumb that's actually the opposite conclusion from results of actual research into the issue (granted it's not exactly a deeply studied niche but there is research).

E.g. if you have 4 long lines all following the same pattern with minor modifications, the best way to both scan quickly and avoid bugs is to write them on their own line fully and align the common parts vertically.

Splitting each line into smaller parts for the sake of "vertical scanning" actually achieves exactly the opposite in this case.

On my typical developer laptop a full-screen terminal window (which I personally never use) with a system default 11pt font is 202 columns. A modest bump to 13pt drops that to 176 columns, meaning I can't view a side-by-side 80-column wide PR diff without some line wrapping.

That's great that you have a 350-character wide display. Requiring everyone to have acres of screen space, either because they can afford a 34" monitor (or 2 24" monitors) OR because they have good enough eyesight to be able to use a microscopic font is excluding a lot of people.

Personally I don't like side-by-side diffs; I'm fine with unified diffs, so I guess I don't run into that problem.

But still, I recognize that nearly everyone else I know codes on a larger monitor (you can get a decent, but not great, 27" monitor for $300 or so) with much more horizontal space, and I wouldn't ask them to cater to my small-screen preferences.

For example, I can dump two files to single column hex using od and then do diff -y to find the bytes that differ. A nice complement to cmp -b.

      test $# = 2||exec echo usage: $0 file1 file2\; for small files
      od -An -tx1 -vw1 < $1 > $1.hex
      od -An -tx1 -vw1 < $2 > $2.hex
      diff -y $1.hex $2.hex|tr '\11' '\40'|sed '/[<>|]/s/  / /g'|less -Jj5 -NGp "[<>|]" 
      exec rm $1.hex $2.hex

I can't believe that in 2021 they still haven't added it.

Most monitors have been wider than taller for many years. Yet, people insist on putting silly horizontal task bars up and down, thus making the problem even worse.

My mind is blown on an almost daily basis when some of our junior developers shares their screen with me.

Two of them consistently have:

1. horizontal task bar

2. display scaling set to 125% or worse (1080 native)

3. a terminal launched from VSCode (whaaaaaaaaaat) they leave on the bottom

That setup leaves them with a total of 30 lines of code. Literally more than 50% of their desktop remains unused most of the time. I don't want to force my opinions on them but stuff like this takes its toll and triggers my OCD. Only it's not an OCD, I just can't see shit

[*] though in all honesty, 1px as a relative measure of angular size is fine, it's just very badly named — I was hoping web designers would switch to ems in early days of the web, allowing users to control everything through font size directly — but that would still require some smartness not to increase padding too much with large fonts: basically, we'd want something like flexible spacing a-la TeX's hskip/vskip/hglue/vglue but catering to the screen and nuances screens possess.

Almost no UI (including web pages) is designed to work well with custom font sizes today. It's a definite win of form over function, or at the very least, recognition that designers are unable to design truly fluid/responsive interfaces that they like the look of.

Gnome still allows you to make use of gnome-tweaks to adjust just the font sizes, but you still run into issues because spacing can be too small (thus I tend to run with 125% scaling and 1.4-1.5x font sizes on HighDPI screens).

That's something I honestly never thought about. I'll try it on the side for the next week, thanks for sharing the tip!

> 2. display scaling set to 125% or worse (1080 native)

Be grateful that your vision is still great I think. I have Hacker News on 125% because it's hard to read for me when it's smaller than this.

That's very interesting and something I never really heard about before. Thank you for sharing that, I spend a lot of time in front of the computer so dedicated glasses would make a lot of sense.

I use an horizontal task bar, out of habits and default parameters, I guess. However, I considered putting it on the side, haven't tried it seriously, but I do like having the title of the tasks and that would probably not be so comfortable vertically.

There are only so many lines of code my brain can handle anyway and I don't think the screen height is not the bottleneck.

I don't know why the huge, pointless icons are the default.

I mostly don’t need my terminal after getting docker up and running, and if I just want to view the output, I can always open it (Control + V).

And I usually have vscode and chrome open.

I usually don't like IDE terminals, they don't do anything that you can't do in a real terminal, but comes with all kinds of problems that wouldn't be accepted on a single purpose program. But that's my preference, yours is fine too. The only real problem is leaving stuff eating up a portion of the screen when you are not using.

Other than that, I don't like to leave my editor to switch to a terminal. Thus when I develop I usually use the VSCode terminal because it's more practical, to compile, run tests, use git (yes, I know that VSCode has git functionalities built in... I find the terminal more practical and fast)

You may have missed the "[that] they leave on the bottom" part of 3. It sounds like you don't leave your terminal open/visible unless you press ^v

That is what makes the most sense if you want to have as much information there as possible.

No one has ever advocated 80 because of hardware limits. Hardware has progressed but our eyes haven't.

In prose, shorter lines help because you can easily go to the next line.

For programming, shorter lines help because you can navigate your function better because most of what you're tracking is in a smaller area. With long lines you have to move your eyes more.

Shorter lines also force you to write one param per line when calling a function. No one is saying you need to mk yr vrbls shorter.

Disagreement does not mean "bad faith".

The character limit is 80 because of hardware. The argument for using 80 characters is not "use short lines because it's easier to read". It's not "use 85 characters if it increases readability and understanding". It's "80 characters is a hard limit and if you go over we're gonna wrap or truncate"

Yes. It is 80 and not another number only because of hardware and history. It has never been about readability.

And this is unconditionally good why?

Linus isn't wrong when he describes lines as a natural unit, already operated on by our tools and our brains. Having to stitch multiple lines together has its own mental cost.

Is a longer line always better? Definitely not. There are absolutely cases where an expression split over multiple lines and well-indented can make code much clearer. There are also cases of the inverse, where you have to take a single atom that was split across multiple lines and re-integrate it while reading. (The patch that Linus is referring to here has some of these.)

Line length should be driven by some combination of total character width and expression cohesion.

A single line can be overly complex even far below an 80 character limit, and a single line well above that limit can still be easy to read.

Prose, and therefore comments, have different reading patterns and therefore different motivations for line length. You want to limit comments and documentation to 80 characters? Fine. Code? That's valuing one metric over another, or simply hoping that strongly clamping one metric is going to also improve another.

One param per line of a function call is bad for readability (unless there are more than four params).

Albums are the length that they are because of the technical constraints of the medium: you can only fit so many tracks on a vinyl disk.

However, this constraint has been adopted by musicians as a creative constraint - an album is a "feels right" amount of music for an artist to produce. You can tell a story in an album, fit a narrative arc in that much space.

But, y'know, sometimes you need a double album to tell the story properly. Some stories need more room.

I like 80 lines as a guideline. It feels about right, and fits my eyeballs. But I'm not going to let that stop me if I need more space. Some code demands more space.

People who like long lines have no main limit they agree on and if a line limit does exist, it often varies by project... making it even more arbitrary.

    class X {
        function Y {
            for (i < 20) {
                if (array[i] == 17) {
                    // just 64 characters left now

For comment blocks, I try to stick to roughly 80 chars per line, but that then is text which can be broken up easily. For program code, I try to stay below 100 chars but exceptions can be made, if breaking up lines would be detrimental to the structure. With very complex function calls though, one would switch to multi-line breaking, sometimes with one argument per line (and a posssible comment).

This discussion makes me wonder, why there are no editing modes with "smart" line wrap. As in being syntax aware when wrapping long lines. A function call which extends the set limit, like the 80 chars, could be automatically displayed as a multi-line call, properly indented. So independant of your terminal size, you could always see nicely looking code optimized for that terminal, without imposing your perfect view size onto others.

Of course, this is easier to do with languages, which have a very strictly agreed upon code style. Go for example would make this easy, as all Go code usually gets autoformatted by gofmt. Lisp would be another language suitable for this, as the syntax makes this easy and overall code-formatting and indentation is pretty universally agreed upon.

But the actual code should be unwrapped. This would also cut down on format discussions.

When typesetting code (which is what we are doing when discussing line limits), natural questions to ask are:

1. Why have a line length limit?

2. If there are reasons to have it, what should it be?

3. Should it be in characters or actual width?

It seems that there's no (big) disagreement that we should have a length limit on lines in code. If you are disagreeing, none of the stuff below matters :)

When it comes to what it should be, a limit of 80 has proven to be sufficiently long not to impede development, and is likely just good as any (you get benefits like multiple side-by-side-by-side windows on wide screens, yet you need to break lines more often; you need to factor your code more carefully to avoid too many indentation levels, yet you can't use sufficiently expressive symbol names....).

If you decide on any particular limit (100? 120? 400?), you'll still have cases where you need to break up long lines. The tools argument (grepping and such) is thus rendered moot, because you've got all the same problems, just less frequently (and that's probably scarier, because it'll be easier to miss something when refactoring).

Finally, the question of monospaced fonts is a curious one: unfortunately, I know of no code editor that works well with non-monospaced fonts, so I've never seriously considered not using them, but the only place where I truly care about fixed-spacing is indentation. And since that renders equally in non-monospaced fonts, I'd be willing to get rid of them too ;-)

I would chop the arguments, putting a single one on each line.

Getting to know those simple gotchas about where to avoid line breaking can help with both prose and code writing.

Keeping to a shorter line width makes me write shorter functions with less nesting. In my opinion that leads to higher quality code which is more readable (your mileage may vary, I write Erlang which is very terse and expressive which fits that style very well).

And code editors are decent at wrapping lines nowadays, if you like it.

Good code is readable code (so even if it's bad code, it's clear why it is so). What you lose with 80 character limit, you also win just as much.

What gets me is long verbose names.

noun-verb. Short names. They are mnemonic not descriptive

IDE can show it automatically when you focus on the name in the source code.

It also depends on how wide the scope is. "i" for an index variable is often a good choice. For the global count of eyes, "i" is a terrible choice.

So in a limited scope I would tend to: kerfuffled:bool

fcntl

goDisplay() rather than initialiseDisplaAndEnterDisplayModeIfEverythingIsOk

  1> (let ((q (quantile 0.9)))
       (each ((l (flow "git ls-files '*.c' '*.h' '*.tl' '*.y' '*.l'"
                   command-get-lines
                   open-files
                   get-lines)))
         [q (len l)])
       [q])
  63.9840684046716

The 99th percentile:

  2> (let ((q (quantile 0.99)))
  [ .. SNIP ]
       [q])
  78.9882857548558

When we go to the 99.99th percentile, things take a bit of a leap:

  3> (let ((q (quantile 0.9999)))
  [ .. SNIP ]
       [q])
       [q])
  104.790549931036

Moreover, if we want to be quite generous, we don't have to add too many columns. 105 characters will only break 1 in 10,000 lines. Something can almost certainly be done about those. Or these outliers have something wrong, like being accidentally joined or something.

--

Let's tidy up the code, by eliminating the each iteration with mapdo:

  1> (let ((q (quantile 0.9999)))
       (flow "git ls-files '*.c' '*.h' '*.tl' '*.y' '*.l'"
         command-get-lines
         open-files
         get-lines
         (mapdo (opip len q)))
       [q])
  104.790549931036

I'm all for >80 column wide lines I just don't think these stats really tell us anything about it other than 80 column lines have been the standard in the past.

It'd be great to get a distribution graph as well, even if we can't know how long would the lines have been without a line length limit.

My gut feel before reading your comment was that:

* I like short limit because majority of the lines _are_ short

* Shorter line length limit allows me to have more windows side-by-side-by-side, without wasting whitespace on the right side

* I am willing to accept occasional awkward line break to achieve the above

The question I had in my mind was how "occasional" was it, so thanks for answering that to a large extent. We could also do a deeper analysis to re-format all lines not to use line-breaks before running the numbers too.

Basically, if 64 was the natural limit for 90% of the lines (sure, some are this short because of the 80-character limit), then a 20% buffer should be good enough.

But if I'm working in a code base where all the lines are broken at <80 characters, it makes sense to stick with that rather than introduce inconsistent formatting.

Bottom line, your brain will adapt to either style without a lot of fuss, and consistency helps.

When I develop new tools, I try to keep the default output within 80 chars if possible -- not because of terminals -- but because of all the other locations the output may appear.

* also for jira tickets, github threads, random blog posts, etc., for the output to stay on screen without fiddling with a horizontal scrollbar.

One of the most productive policies you can do to a company is make autoformat mandatory and move formatting discussions from specific commits to discussions about the formatting rules themselves. If you want to make a change in formatting, you have to write a rule to make it done automatically at the very least.

Plus the whole modern hardware comment is not well founded, since I like to put some monitors in vertical orientation.

And prior to Linotype, there would have been practical limitations to the forme size that could be easily managed and quickly re-set to fix typos.

So I don't think the newspaper column width was the result of centuries of experimentation into readability. It Just Happened. (Same as the gauge in railways)

I think you're right about it being a way to deal with a physical limitation, but not of the physical type -- rather, of the physical paper. If you divide the page vertically into two or three columns (for magazines) or six to nine (for broadsheets), you get an extremely flexible grid to use for fitting stories around one another and around photos and advertisements. Text could be a single column wide or two or even three columns across; headlines can run across just a column or two or across the whole page; you can always find somewhere to put that story that continues from page 1A.

  some_long_variable_name = 42
  new_value = description_function_name(some_long_variable_name)
  do_something_with(new_value)

Go further, and you could even have a file to map one or more variables to a different name, so that is someone prefers "avg_val" and you prefer "average_value", then you could both see the different name, although that starts to get dangerous as you discuss the same code with different syntax but the same semantics.

Kernel coding style guide:

"Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program."

When I write my own code I try to not get after the 100th column on the line though (and that is never 100 characters per line with all the indentation going on).

But in case I stumble on code with long lines, I'm still fine.

One should also not forget that some language some of use are forced to work with are incredibly verbose (a combination of culture, lack of type inference, the existence of every and any modifier under the sun, etc.).

    ECPrivateKeyParameters privKey = new ECPrivateKeyParameters(privateKey, Sign.CURVE);

And that's not an hardcore example: this is relatively soft.

Now thankfully, like Linus, I don't think 80 characters-wide code makes any sense at all whatsoever in 2021 (not that I especially like verbose language btw).

Anything more than 140 or so and it gets harder to scan (too sparse). Anything less than 100 or so and it gets harder to scan (too dense).

80 is just painful.

    I do get
    tired of reading code that isn
    't formatted in
    a
    clear way because the autoformatter is
    a slave to the column limit and
    especially in the case of 1. lists
    2. instructions. 3. Other things that
    should line up--is overzealous
    in breaking up lines and making the
    code as unreadable as possible.

I don't mind going past 80, but would still want some de-facto standard, and there's a fair amount of precedent for 132.

The rationale for the 110 is that above that you cannot avoid wrapping in a side-by-side diff on a reasonable screen+font+layout. 90 is where you should be asking yourself "is this cleaner to split across multiple lines?" and still allowing some headroom to make minor changes without needing to reformat things.

There are of course some things where it is impossible to constrain things to shorter lines (e.g., markdown tables) but those are definitely the exception.

As part of VT-100 compatibility, many subsequent terminals also supported 132 column mode.

I always kind of figured "132" was some arbitrary programmer decision, never knew it dated to old terminals. At least I recognize 24 and 43 as the number of lines old text modes (on, eg, VGA) had.

I know the DEC VT340 was capable of 132 columns, as was an Apple II with a Videx Ultraterm card and a suitable (hi-res) monitor.

There are probably even more examples, but those two are what came to mind first.

An utterly confusing situation.

    // Get the ids from the data
    var ids = object.stream().map(object->
        object.getName() + object.getType()
    ).distinct().collect(Collectors.toList());

    // Get the ids from the data
    var ids = object.stream()
                    .map(object ->
                         object.getName() + object.getType()
                    )
                    .distinct()
                    .collect(Collectors.toList());

The reason that's the best choice is that it's the approach that provides logical data rather than a specific visual style, allowing people can just configure their editors to do word wrapping to whatever line length they prefer and set tab width to whatever value they prefer (including fractional values!), so it's strictly better than all alternatives.

And if someone doesn't like the editor word wrapping, they can always write an extension or patch for the editor to wrap in whatever syntax-aware way they want.

Also, while for some other bizarre reason it's traditional to program with monospace fonts, there is in fact no reason at all to use them instead of the more efficient proportional fonts, and if you use proportional fonts the concept of a length limit is meaningless.

But often you _do_ want to provide a specific visual style with your code. Vertical alignment is a powerful tool for communication and readability. Hence monospace and space-based indentation.

Also, word of advice: when a disagreement has been running for decades and involved thousands of people on both sides, casually describing your conclusion as "obvious" and belittling anyone who disagrees as "[not] very rational" signals superficiality, not intelligence.

That aside, I'd say the reason your vision is not achievable today is due to lack of great view/edit tools.

https://nickgravgaard.com/elastic-tabstops/

I've found that the last reason I can justify spaces has to do with hanging indents which are not aligned on tab bounaries. Elastic tabstops handles those with - you guessed it - tabs.

    {
        {
            {
                {
                    {
                    }
                }
            }
        }
    }

    {
        {
           {
             {
              {
              }
             }
           }
        }
    }

- prose and comments are greatly improved with shorter lines (I switched to reader mode to read the post)

- a logical code line often exceeds optimal prose length (70-80), due to indentation, syntax, language idioms etc

- code is more sparse and much less visually homogenous than prose, which means code can have longer lines without causing "staccation return issues"

- it is technically easy and non-destructive to auto wrap in-editor for display output (long source -> shorter display)

- it's ambiguous and hard for an editor to "unwrap" (short source -> longer display)

- grepping source works better with less wrapping

- diff tool UIs seem to struggle with long lines, today

- some single identifiers are commonly longer than 80 - such as URLs

- comments and code doesn't have to have the same max length

Linus got it right in this case imo. In the future, I'd be curious about ubiquitous and standardized auto-wrapping in editors so that you can set whatever length you damn please without imposing it on everyone else.

What I don't worry about is long function names or similar. I won't wrap a line because a function name is really long or similar, as I think that doesn't generally add more complexity to the line.

That being said I think soft-wrapping of code is very lacking. The best I have seen is matching the indent of the previous line. It would be neat if it preferred breaking on separate arguments, operators etc. I guess this is now moving to the realm of code formatters but now you are back to hard-wrapping which loses the info about the target screen size.

https://lkml.org/lkml/2020/6/5/685

To summarize, this blind user at least doesn't consider 80-characters max width to be a supportive argument. They are more worried, instead, about matching up the terminal width to multiples of their display. And of course, to avoid forced guis.

Sometimes I think it's easy to make arguments about accessibility without actually consulting someone with an accessible need.

Nicolas Pitre wrote: "Well, not really."

Is that the "response to the response" you're referring to? If so, that's what I meant as well. I thought Nicolas' response was on point with the discussion about accessibility.

I think all of this stuff is an art not a science but I'd rather people didn't go much over 100 chars, it becomes really difficult to read and I'd argue in most cases there should probably be descriptive names given to parts of a long line in the form of variables/constants. Maybe this doesn't apply to kernel development but I love to name things really descriptively rather than giving things short names or building clever one liners.

Plus, you're most likely not going to check this conversation in into git. And you're probably not going to pipe it into grep. :^)

I tried a few different thresholds over the years and I finally chose 100 chars. It is a good compromise, wide enough to not be obnoxious and enabling long names.

And still narrow enough to display two columns on a single wide screen when needed.

Even the simplest improvement in line wrapping of maintaining the leading indent is pretty much enough. Once I started using Atom and then VS Code, which both do this, I pretty much stopped worrying about line length except when it was semantically confusing (like many arguments to a function where I use newlines to separate the top-level arguments from the expressions).

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

I get the argument that you shouldn’t bring down the experience for everyone just to accommodate the most limited imaginable scenario (80x22) when it comes to breaking code lines, but it’s pretty easy to just replace <pre> with <p> in the context of the LKML listings.

100 soft/best effort limit, 120 hard limit (with exceptions), 150 absolute limit (rarely used), 72 limit for docs/comments.

Auto-formatters usually set to 120.

More than 120 does come up, but very rarely - e.g. long URLs in documentation.

So what is the recommended style for line length in the Linux kernel?

Most arguments can be translated to "because I like it this way".

  (80*2+ui+browser)*legible-dpi
  == age/2

Side rant, I have a lot more issues with people writing functions that are 500 lines long and contain 10 individual sets of logic which would make sense to be fragmented in different functions. As a matter of fact I had a fight over this at my now old job. Ideally the body of a function should fit in one screen: ideally 60-80 lines. In fact there is a study on the subject described in "The Psychology of Computer Programming" [1]. If it's something larger, in 90% of all cases you can segment your logic in a way which allows one component to be responsible for one specific thing and take that out in a separate function. With good naming, this makes the code infinitely easier to read 6 months down the line when you have to figure out what someone else or even you have done. The argument I got was "Well what if I have an ultra-wide monitor set up vertically, then it's not a big deal?". Fffs, are you stupid??? What if I start coding on my 4k projector and I can fit 1000 lines in a single screen? Fetch a vector from one place, iterate over it, populate a hashmap, compute some standard deviation, save a backup on disk, check the bounds of the values, store them somewhere for future reference and call an async function to a message queue, check if a set of conditions are met and have 8 different fragments of code handling those based on the conditions that were matched. Function name: fetch_history_data. There's a lot more than fetching history data in there now, isn't there? End of rant, I think I had to get it out of my system.

[1] https://www.goodreads.com/book/show/1660754.The_Psychology_o...

It is common for people to use split-screen setup (two files / editor buffers in parallel). On common 1920x1080 screen with 10px-wide font, you have 2x96, so something like 80-90 columns is ideal.