But no, 80-column terminals in 2020 isn't “reasonable” any more(lkml.org)
lkml.org
But no, 80-column terminals in 2020 isn't “reasonable” any more
https://lkml.org/lkml/2020/5/29/1038
321 comments
> 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.
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.
> 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.
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.
> 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.
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.
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.
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.
> 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.
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.
> 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.
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.
When is shadowing is right thing to do? Why picking a new variable name wouldnt work?
No matter what I say here, I feel it would be very likely you will tell me I'm wrong.
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
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
> "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.
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.
To be fair though, if you have class names like AbstractSingletonProxyFactoryBean, then terminal width is the LEAST of your problems.
You may be in a position where using a verbose framework or libraries save you way more effort than the small pain they bring.
You may also be in a position where you can alias those names to something more reasonable.
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.
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.
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?
Really, is there any writing that doesn't seem to apply?
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.
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.
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.
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.
>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.
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.
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.
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.
> 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
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
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.
When long lines improve readability/ clarity you should have the ability to use them.
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.
> ...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.
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.
> 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.
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.
I mainly use Clojure and keep most of my lines under 80 characters.
> 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.
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.
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.
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?
In a 100 char wide code line, how many actual non-whitespace chars would there be on average?
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.)
(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.)
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.
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.
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.
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.
> 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
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
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.
If I did work for Google, with their heinous 2-space tabs, I'd certainly do that all the time.
> 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.
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.
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.
Ah so you're "tabs" haha
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.
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.
Yep. I have yet to hear a coherent argument against tabs.
It’s such a tiresome squabble.
It’s such a tiresome squabble.
Douglas Crockford made an interesting argument in favour of spaces: https://www.youtube.com/watch?v=En8Ubs2k1O8
Vertical alignment of related lines.
If you indent with tabs, you can still align with spaces for vertical alignment.
That’s the whole point of tabs. How is this an argument against them?
Because it doesn't work with tabs, someone else will have a different tab-width.
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.
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.
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.
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.
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.
Somewhere I have a picture of daringfireball taking up around a quarter of the monitor width and just blank space around it.
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.
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.
> that Windows users are prone to do.
Or how iOS users tend to do.
Or how iOS users tend to do.
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.
And he hasn't optimised the design for iPhone-sized devices much but I think that's deliberate.
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.
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.
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.
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.
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…
Or... You can use and ide for this... (Eclipse have generic text and specific programming search for that)
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.
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.
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.
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.
> 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.
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.
> 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.
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.
> 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.
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.
[deleted]
Then pipe through
perl -pe 's/\\\n//g'
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
No? That just merges continuation lines. So if your original file is
foo(1, \
bar, \
false)
print("Hello, world")
flag = \
true
foo(1, bar, false)
print("Hello, world")
flag = true
foo(1, bar, false)Sorry, what language are we talking about that has escaped line continuations for expressions like that?
Yeah, when you do typesetting you quickly learn that ~10 words per line is a sweet spot for readability.
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 ?
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 ?
[deleted]
> 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.
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.
> 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".
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".
[deleted]
Yeah, bad tools shouldn't justify bad decisions. Build better tools god damn it.
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.
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.
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.
You don't read code the way you read a book or long-form document, as authors generally don't optimize for vertical reading.
Details matter.
The way I'm set up at my desktop, my editor can fit ~320 columns. Which means I can fit four 80-column-wide files side by side. Three, if you account for line numbers on the margin.
(I usually do two, because my code tends to go up to ~120 characters.)
The way I'm set up at my desktop, my editor can fit ~320 columns. Which means I can fit four 80-column-wide files side by side. Three, if you account for line numbers on the margin.
(I usually do two, because my code tends to go up to ~120 characters.)
The more reasons to use narrower lines, right? I mean, I work in two files side by side 50% of the time, and with 120 chars the text would require wrapping, which is really unreadable in e.g. python.
Personally, I prefer handling long lines via horizontal scrolling (with keyboard shortcuts) rather than wrapping.
I would be more sympathetic to 80 column limits if Linux didn't have indent set to 8 columns.
This was a solved problem with tab indenting. It's a bit unfortunate that space indenting won, but I understand why.
What do you mean? Linux uses tabs.
Winning doesn't mean completely extinguishing the competition.
Not really a solved problem. Even if you set your editor to display 1 tab as 2 columns, another person may set their editor to display 1 tab as >2 columns. So even using tabs, a project has to set rules for tab width.
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.
If you don’t like your tab width, CHANGE IT. That’s a huge win over spaces, where indentation is hard-coded.
I somehow forgot to add the essential part of my comment. Sorry, here it is:
If someone prefers a narrow tab width and breaks lines based on that, then someone who prefers a wide tab width will get overfull lines:
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
If you nest code that deep, you probably should extract some logic into separate functions.
I remember Linus saying that explicitly.
I remember Linus saying that explicitly.
> It's more of an anatomical restriction: the resolution of the human eye and the field of view.
The restriction on code length to 80 has absolutely nothing to do with the resolution of the human eye or your field of view.
> For example, if we had 10 meter-wide monitors we won't be able to see them entirely from a close distance. Increasing the distance will require to increase the font, so the number of characters per line we can use doesn't change much.
Again, this isn't relevant to the question of say, 80 cols vs 100 cols vs 120 cols. No one seems to be saying cols should be unbounded in length.
> Not so long ago I showed a piece of code on a mobile phone screen to a colleague, saying he should use shorter lines. He replied I need a larger display. When I opened the same code on my desktop display the lines were not fitting the editor window almost the same as on the mobile screen. (We keep phone closer to eyes so can use smaller characters).
I'm not sure how this is an argument for 80 cols other than the already addressed "I limit my development environment to 80 cols".
The restriction on code length to 80 has absolutely nothing to do with the resolution of the human eye or your field of view.
> For example, if we had 10 meter-wide monitors we won't be able to see them entirely from a close distance. Increasing the distance will require to increase the font, so the number of characters per line we can use doesn't change much.
Again, this isn't relevant to the question of say, 80 cols vs 100 cols vs 120 cols. No one seems to be saying cols should be unbounded in length.
> Not so long ago I showed a piece of code on a mobile phone screen to a colleague, saying he should use shorter lines. He replied I need a larger display. When I opened the same code on my desktop display the lines were not fitting the editor window almost the same as on the mobile screen. (We keep phone closer to eyes so can use smaller characters).
I'm not sure how this is an argument for 80 cols other than the already addressed "I limit my development environment to 80 cols".
I have a certain monitor width, distance from that monitor and font size. Those constraints dictate how many open file columns I can fit across my screen. I'm happy if I can get two columns, so that I can edit files side-by-side. 80 columns is the approximate sweet spot.
The suggestion that people should just get "better hardware" is so completely asinine, because it neglects to realize that the quality of hardware might not be the problem. For example, instead of having a single very large monitor, I use three somewhat smaller monitors because that enables other productive workflows.
The suggestion that people should just get "better hardware" is so completely asinine, because it neglects to realize that the quality of hardware might not be the problem. For example, instead of having a single very large monitor, I use three somewhat smaller monitors because that enables other productive workflows.
He never said to buy better hardware. He said the code should no longer be formatted based upon what he believes to be a niche situation. People in this situation can, in fact, still edit code. You will get line wrapping. It's not optimal, but neither is editing 80 lines when you have 100 available.
You missed my point. My point here is that reasonable people can disagree if you just take a second and think about others' perspectives, workflows and development setups. But no, Linus is literally arguing that reasonable people cannot disagree because he's arguing that an 80-column limit isn't "reasonable." That's a bunch of bullshit.
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.
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.
> 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.
This is so clearly right, how can it not yet exist?
‘Just’ dynamic virtual pretty print per personal lang style prefs.
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.
Xcode on OS X has been doing this for at least one decade.
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).
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.
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.
The editor could show both the final line number and "sub-line-numbers" after a decimal point or something. E.g.:
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.
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 }
1 /* A function that does something */
2 int do_something(int foo, int bar, int baz) { return foo + bar + bam; }
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 }
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.
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.
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.
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.
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.
No text editor that I know of intelligently word wraps code. Vim doesn't and Emacs doesn't either.
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.
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.
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.
[deleted]
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.
I think the pragmatic solution is an opinionated linter that can be broken.
Now that you’ve said it you have to make it happen!
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.
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.
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.
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.
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.
Interesting. I, too, use 120. It makes diffing code easier.
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.
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.
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.
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.
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.
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.
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.
Yes, and human eyes are bad at tracking lines beyond a certain length.
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.
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.
How can you make a linter for this?
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.
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.
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.
Use warnings for long lines instead of errors?
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.
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.
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.
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.
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.
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.
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! :)
He said, wow, Windows is really nice! :)
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
Hammerspoon can do this (and way more!) for free :)
https://www.hammerspoon.org/go/#winresize
https://www.hammerspoon.org/go/#winresize
It’s _literally_ the first app that gets installed on a fresh machine for me.
I'll have to try this.
I recommend the open-source macOS window manager "Rectangles". You can install it using Homebrew or download it from their website:
https://github.com/rxhanson/Rectangle
https://github.com/rxhanson/Rectangle
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
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
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.
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.
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.
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.
macOS has supported left-and-right snapping ("Split View") since 10.14. Maybe your accidental demo was the inspiration!
Macs have been doing that for ages.
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)?
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)?
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.
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.
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.
Personally, I like 80 character lines. If I need more than 80 characters in a line, I treat it as a code smell.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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
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
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.
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.
We should be focusing instead on the contextual and cognitive pros and cons of various line lengths.
> 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...
There's no more room on a 43" 3840 x 2160 monitor than there is on a 32" 3840 x 2160...
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.
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.
Is it a TV? If so does it work well for small text and are there any negatives vs a monitor?
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.
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.
What kind of laptop bag do you use for the monitor?
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.
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.
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.
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.
Sadly, they don't make them with anything under 1.25.
> "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...
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...
> 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.
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.
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.
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.
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.
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.
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.
The vertical was definitely more uncomfortable than horizontal.
Yes this. I have 20/20 vision but as I got older getting some mild reading glasses dramatically improved my development experience.
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.
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.
> 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.
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.
Can't you enable line wrapping in your editor?
Line wrapping is an abomination.
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.
The more interesting question is "what would be a good default line length in 2020?"
I vote for 120 columns.
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).
Next natural values are 106 (for 9px fonts) and 95 (for 10px fonts).
Few use bitmap fonts today, especially with retina displays and whatnot
Github is the new fixed width terminal, and 120 columns is about right for that. That's our standard.
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).
Good line length for 2020 is 80 columns.
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?
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?
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.
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.
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.
I would increase the limit if I can fit more though and I don't mind accommodating others who prefer a higher limit.
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.)
This is what Linus has said in the past regarding soft-wrapping: https://github.com/torvalds/linux/pull/17#issuecomment-56611...
Ironic that his reply is almost unreadable on mobile because of his hard wrapping. Intentional?
Github provides an email to Github comment gateway. So he was composing his replies in his email client.
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 :)
> patches in emails
Cringe.
Cringe.
Give me a better non-locked-in experience than a mailing list, gnus/mu4e and magit and I am happy to try it out.
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"
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"
> 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.
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.
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?
> 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.
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.
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
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
> 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.
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.
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.
I'm pretty sure that most people would prefer their code hard-wrapped at a certain line length.
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.
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.
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.
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.
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...
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...
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.
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.
Isn’t there some merit to the notion that long lines are typically either overly verbose or mentally challenging to understand?
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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)
(I think this is a terrible idea, but also got me thinking if there's something interesting there)
> 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).
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).
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.
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.
Perhaps this could be a new feature for the language server protocol? Or is it already in the works...?
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.
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.
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.
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.
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.
Plus I find that most of the time I just use the default patch view, not the side by side one when doing review.
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?
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?
4 spaces allows you to have manual line wrapping, for example:
if (a < b || b < c || ...
|| d < e || ... )
Do something.
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.
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.
> 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...
- Linus Torvolds
[1] https://github.com/torvalds/linux/pull/17#issuecomment-56611...
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.
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.
my use case is extremely common.
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.
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.
Books are definitely not indented, code can be up to 50% of actual text. In that case 120 columns.
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.
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.
peaks and valleys between functions and such are a huge aid visually -- line wrapping makes visualization of source code harder for myself, personally.
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:
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))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.
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.
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
):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.
As to vertical size: how much crap are you going to put into one function, anyway? Other than perhaps some local (nested) helper functions.
Editors support it fine, but personally I find the result aesthetically unpleasant no matter the editor.
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.
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.
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.
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.
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.
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.
I may be imaging this, I dunno.
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.
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.
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).
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).
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.
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.
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.
At least at work, I feel like my 80 column terminal is probably the only “reasonable” app as far as layout and readability go.
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.
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.
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
[0] https://twitter.com/rob_pike/status/563801489190043648?s=21
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.
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.
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.
Keeping lines short also helps when pasting code to instant messengers or reading side-by-side git diffs.
[deleted]
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.
80 seems good to me.
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.
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.
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).
A vt-100 could do 132 columns and I've always set my terminal windows to that width.
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.
[deleted]
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.
"Does Column Width of 80 Make Sense in 2018?":
* https://news.ycombinator.com/item?id=17436945
* https://news.ycombinator.com/item?id=17436945
Personally, i limit line length to 95 columns - 1920 / 10px wide font / 2 (horizontal split screen) is 96, minus some pixels for borders.
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.
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.
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?
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?
We had only at most 72 positions available on 80 column punch cards, and we loved it! Bring back the 1950s! ;-)
Old enough to remember 132 column line printers and using them to do code reviews. It felt very convenient.
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.
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.
I keep my VT420 in 132x39 mode, but it does take a little longer to redraw the screen at that size.
Text has solved this problem without requiring hard line breaks at regular intervals.
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.
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.
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.
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...
Everytime someone tries to argue for it I want to suggest we swap their Mac for a Commodore 64...
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).
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.
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.
The more you know! Thanks.
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.
80 columns on a C64 is a real reach. You need special hardware (or horribly slow & fuzzy text) for that.
The C128 did have a 80 character mode[1].
[1] https://www.c64-wiki.com/wiki/Commodore_128
[1] https://www.c64-wiki.com/wiki/Commodore_128
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.
That email sure seems to be formatted for 80 columns
I guess his new AMD CPUs can now handle the wider columns!
:-)
:-)
I like 128 because it’s a round number.
I wonder how Linus feels about tabs vs. spaces (I didn't read the entire post, so maybe he addressed it?)
> 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
That is what he says
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.
The kernel uses 8-space tabs.
How do you mean 8 space tabs? Are tabs not single characters \t?
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.
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.
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.
>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,
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.
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);
}
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.
> 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.
It is brain-dead, but that is exactly what is required in many styles.
I really like this wiser version of Linus. Imagine that text five years ago)
Good riddance. If we pick a new suggested width, maybe it shouldn't be based on a 1928 punch card standard.
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
[1] https://llvm.org/docs/CodingStandards.html#source-code-width
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`.
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`.
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.