But no, 80-column terminals in 2020 isn't “reasonable” any more
lkml.org
lkml.org
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.
(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.)
In a 100 char wide code line, how many actual non-whitespace chars would there be on average?
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.
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.
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.
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.
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.
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.
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.
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.
perl -pe 's/\\\n//g'
foo(1, bar, false)
print("Hello, world")
flag = true
foo(1, \
bar, \
false)
print("Hello, world")
flag = \
true
foo(1, bar, false)
print("Hello, world")
flag = true
foo(1, bar, false)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 ?
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.
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.
It’s such a tiresome squabble.
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.
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
If I did work for Google, with their heinous 2-space tabs, I'd certainly do that all the time.
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.
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.
Really, is there any writing that doesn't seem to apply?
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.
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.
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.
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.
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].
When long lines improve readability/ clarity you should have the ability to use them.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
Or how iOS users tend to do.
And he hasn't optimised the design for iPhone-sized devices much but I think that's deliberate.
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.
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.
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".
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.
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.)
If you don’t like your tab width, CHANGE IT. That’s a huge win over spaces, where indentation is hard-coded.
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
I remember Linus saying that explicitly.
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 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.
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.
I think the pragmatic solution is an opinionated linter that can be broken.
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.
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.
This is so clearly right, how can it not yet exist?
‘Just’ dynamic virtual pretty print per personal lang style prefs.
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.
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.
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.
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.
He said, wow, Windows is really nice! :)
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.
This should be standard in Windows IMO. It has absolutely transformed how I work and noticeably increased my productivity.
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 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 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)?
Personally, I like 80 character lines. If I need more than 80 characters in a line, I treat it as a code smell.
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.
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.
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.
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.
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
Sadly, they don't make them with anything under 1.25.
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.
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.
We should be focusing instead on the contextual and cognitive pros and cons of various line lengths.
There's no more room on a 43" 3840 x 2160 monitor than there is on a 32" 3840 x 2160...
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.
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.
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...
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.
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.
The more interesting question is "what would be a good default line length in 2020?"
I vote for 120 columns.
Next natural values are 106 (for 9px fonts) and 95 (for 10px fonts).
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?
I would increase the limit if I can fit more though and I don't mind accommodating others who prefer a higher limit.
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.
Cringe.
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"
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.
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.
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.
And you still haven't described any of them.
> It's just hostile in so many ways if you aren't using a VT-100
That's a strawman. At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote. You're going to have to learn how to deal with code conflicts, resolve them and push up the resolution. You can certainly participate in the email patch workflow with a GUI email client and a few git commands either executed on the command line, or may be as part of a graphical git GUI client.
> where the other side is just not interested in improving the process
I already mentioned a few things in my reply to williamdclt pertaining to tl; dr documentation for setting up git format-patch and git send-email much like Github displays the commands to clone, set the remote, push and pull commits. But I don't think it's fair to say they're not interested in improving the process. For example, a new utility called GitGitGadget was written to provide an interface between Github pull requests and the Git mailing list and it's also mentioned in the Documentation folder of the git repository [1].
> in the end the reply will just be "it's all so perfect, look how easy and nice it is"
The problem is that you're being too dismissive in your criticism and comments rather than specifically describing what could be improved within their process. Effectively telling a project that they need to discard a process that they've successfully used since its inception and move to an entirely new process is a non-starter.
> I also know that being specific with an evangelist will just get me a reply "oh just rent a VPS if your ISP blocks SMTP"
Some people prefer to run their own SMTP servers rather than use Big Company's product. In my case, I have no problem doing this through the email account I have with my ISP.
> If you really can't admit to see a single fault with the system, you are evangelical.
I did mention in my other reply that the documentation for setting up the environment could be more concise, but not everything that's old is necessarily worse or obsolete. A lot of Webapps perform worse in terms of latency and input lag on my laptop with a multicore processor, gigabytes of memory and over a terabyte of secondary storage compared to the equivalent desktop application from decades ago on a machine with megabytes of memory, a single core processor running at less than a quarter GHz and secondary storage less than a quarter GB.
[1] https://github.com/git/git/blob/master/Documentation/MyFirst...
How? That workflow assumes a 80-char b/w terminal for the most part. Try using any part of it on mobile or with large font size due to bad eyesight, it's awful.
> At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote.
Well... no, you don't have to.
> In my case, I have no problem doing this through the email account I have with my ISP.
In your case...
> The problem is that you're being too dismissive in your criticism and comments rather than specifically describing what could be improved within their process.
I have tried being very specific, just one sentence later you prove my point, it doesn't work and gets dismissed. I really don't plan on playing that game until I die of old age. Thankfully GitLab/GitHub et al have started the "fight" for me, making the workflows much more accessible and losing quite a few B/G-era relics.
> Effectively telling a project that they need to discard a process that they've successfully used since its inception and move to an entirely new process is a non-starter.
Yeah, this is exactly the answer I spoke about and have gotten, blanket dismissal and being set in old ways. There isn't a piece of workflow that they're/you're willing to move out of that toolset. Quite a few projects still enforce 80char columns, it's a testament to the fact that even the smallest things can't be changed.
> A lot of Webapps perform worse in terms of latency and input lag on my laptop with a multicore processor, gigabytes of memory and over a terabyte of secondary storage compared to the equivalent desktop application from decades ago on a machine with megabytes of memory, a single core processor running at less than a quarter GHz and secondary storage less than a quarter GB.
Yeah and you uploaded your patchsets for minutes if not hours. God forbid you had to download anything with any size at all, sometimes it took days. The non-stop hassle of having enough disk space. Delivering files via snail-mail and floppies was sometimes a viable option. Not to mention the equal amount of rather buggy and cumbersome software.
It wasn't all bunnies and flowers you are trying to imply it was. Some half-a-second slowdown, some minor input latency is not a valid reason to dismiss an entire set of tools. Not to mention, git doesn't really shine with it's responsiveness in quite a few cases.
There's nothing stopping you from using a gui text editor to edit the code and there's nothing in git commits or the code itself that forces wrapping at 80 characters. Email clients certainly can wrap text at longer line lengths if configured to do so.
> Try using any part of it on mobile or with large font size due to bad eyesight, it's awful.
I don't try to do any serious development on my mobile. Having a machine with a reasonable size screen along with an actual keyboard makes things much easier.
If you're referring to hard wrapping, you're probably going to have to deal with that for most source code anyway no matter what line length. Soft-wrapping lines that exceed the screen width makes code and diffs less readable. For text in the email that doesn't require hard wrapping, there is an RFC[1] that defines a additional format parameter for the Content-Type header. Clients that support it will softwarp text, but email clients that don't will just show the original hardwrapped version.
> I have tried being very specific, just one sentence later you prove my point, it doesn't work and gets dismissed.
The git project, specifically, has been using this process since its inception (around 2005 IIRC). They inherited it from the Linux project which had been around for several years longer than that. In fact, the process pre-dates git itself and git was written with that process in mind (which is why they have commands that can serialize commits to and deserialize them from email).
But, like I said, telling a group of people as an outsider that they should drop the long standing process entirely which has been working well for them and go with something different isn't going to gain any real traction. This is regardless of the domain you're dealing with.
> Yeah and you uploaded your patchsets for minutes if not hours.
Most patch sets probably don't exceed several hundred lines total. Even on dial-up, you're talking about less than a minute.
> God forbid you had to download anything with any size at all, sometimes it took days.
Patch sets aren't really that big. The only thing that took a while with email or newsgroups was messages with attachments or having to download a lot of headers. As for git, the only process that may take a while is git clone. git fetch and dealing with email would work just fine over dial-up.
On the other hand, I seriously doubt that webapps like Github or Slack can work over dial-up speeds. For instance, if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable, but I can still receive and send email without any issues.
> It wasn't all bunnies and flowers you are trying to imply it was.
If you were talking about downloading images, mp3s, etc, then, yes, it took a while, but those things aren't relevant to text patches, email, or git.
> Some half-a-second slowdown, some minor input latency is not a valid reason to dismiss an entire set of tools.
I use Slack and Github Enterprise at work. On a 100 Mbps downstream connection, I have to wait for 10 to 20 seconds for a PR to load up when it has more than 20 comments. When I type in Slack, there's a noticable input lag that develops over time (on the order of seconds) and I have to refresh the Slack window several times a day to get rid of it). Sometimes, I try to mark messages as read and my browser tab freezes until it gives me a prompt about a script causing a slowdown. If I stop it, then Slack is unusable and I have to refresh the page to recover.
I simply don't recall having these issues with email or IRC (or even some of the other chat clients like ICQ, AIM, MSN Messenger, etc), and all of them worked perfectly fine over dial up and on machines that significantly less computation speed and available memory.
> Not to mention, git doesn't really shine with it's responsiveness in quite a few cases.
It really depends on what you're using git for. If you're storing large binary files or very big mono-repos, then it's not the right tool to use. Similarly, tools like Github aren't the right tool to use for certain projects that deal with many in flight patch sets that require in depth discussion and not having the platform shut down accounts of certain users due to issues the US government has with a number of other countries around the world.
Very clever leaving out the third component here that does force it.
> Email clients certainly can wrap text at longer line lengths if configured to do so.
Assuming someone hasn't banally pre hard-wrapped the text.
> I don't try to do any serious development on my mobile.
Who said anything about serious development, you basically can't even check a patch out on mobile without some major hassle. Plus you also ignored the general accessibility problems.
> If you're referring to hard wrapping, you're probably going to have to deal with that for most source code anyway no matter what line length.
Source code can be displayed using a code viewer, nicely, it works. Comments can be displayed using a text viewer, using text fonts, nicely, it works. Non-HTML e-mail conflates the two, the resulting amalgam is vomit-inducing.
> But, like I said, telling a group of people as an outsider that
Nah, this reply is given to even insiders that don't want to deal with that obsolete shit.
> they should drop the long standing process entirely which has been working well for them and go with something different isn't going to gain any real traction. This is regardless of the domain you're dealing with.
I can say my ten-year-old laptop "works so far", but is it good, no, not really. It's really a rather weak argument to resist even changing the tiniest things.
> if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable
Fix your home network.
> but those things aren't relevant to text patches, email, or git.
You're still pretending that it was fast even with text patches, e-mails or git.
> simply don't recall having these issues with email or IRC (or even some of the other chat clients like ICQ, AIM, MSN Messenger, etc), and all of them worked perfectly fine over dial up and on machines that significantly less computation speed and available memory.
Yeah, you have other issues with IRC. Not to mention, no, they didn't "work perfectly over dial-up".
> It really depends on what you're using git for. If you're storing large binary files or very big mono-repos, then it's not the right tool to use.
It depends if you're using it or not. It's slow even on medium-sized repositories. Things don't happen in an instant like you pretend them to do.
> Very clever leaving out the third component here that does force it.
Which component is that? The SMTP protocol? According to [1], the maximum line length allowed by SMTP is 1000 octets, which is well over any maximum hard-wrapped line length for typical source code lines.
> Assuming someone hasn't banally pre hard-wrapped the text.
Hardwrapped text is only a problem for displays that cannot display lines as long as the hardwrapped line length. It's not a problem for displays that can display lines longer than that. To me that indicates that if enough people are using mobiles to read code and patches, then we should consider line length limits significantly less than 80 characters.
> you basically can't even check a patch out on mobile without some major hassle.
Mobile email clients are not suited for reviewing patches due to the fact that they typically use variable width fonts and do not provide a way to post replies inline with quoted text. But that certainly could be fixed by connecting to a machine and attaching to a screen or tmux session to review a patch.
> Nah, this reply is given to even insiders that don't want to deal with that obsolete shit.
Citation please.
> I can say my ten-year-old laptop "works so far", but is it good, no, not really. It's really a rather weak argument to resist even changing the tiniest things.
Changes should improve on what's there, not go off on a different tangent. Github wasn't even originally designed for code review and it shows. The fact that you can't have threaded discussions (like Hacker News or reddit, not like Facebook) or Twitter) on a line of code, treating commits as something completely dissociated from the review doesn't sound like an improvement to me.
> Source code can be displayed using a code viewer, nicely, it works.
Looking at my python code on Github on my mobile, I find that I have to scroll from side to side to view the code which is wrapped to 79 characters or less for most lines. That's no different than viewing it in a window that does not softwrap the code. How would this be any different than viewing an email with the softwrap setting turned off?
>> if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable
> Fix your home network
Why can't those tools work when I'm getting 5 to 10 kB per second downstream? Email and IRC work perfectly fine. It's the same thing if I only have a GPRS connection on my mobile. You might call protocols other than HTTP obsolete, but they still work when you don't have that much bandwidth.
> You're still pretending that it was fast even with text patches, e-mails or git.
Exactly how much experience do you have on the internet at dial-up speeds? I was using dial-up from 1995 through 2005. Emails, whether they contained correspondence or patches simply did not take a noticable period of time to transfer.
I'm not going to bother reading the rest of your response because you're just arguing for the sake of arguing.
The wetware component enforcing some line length - some old maintainer stuck in his ways. I don't see what you're trying to achieve ignoring that?
> Hardwrapped text is only a problem for displays that cannot display lines as long as the hardwrapped line length
You're incorrect, it's a problem on wider screens as well.
> Mobile email clients are not suited for reviewing patches due to the fact that they typically use variable width fonts and do not provide a way to post replies inline with quoted text.
Again, that's an issue caused by non-HTML e-mail that's currently enforced in way too many places. It's not a problem with any e-mail system that is even somewhat modern.
> Why can't those tools work when I'm getting 5 to 10 kB per second downstream?
That's not the issue, your network's QoS is bad.
> Exactly how much experience do you have on the internet at dial-up speeds?
Years, more than enough to know it was absolute shit.
>> Nah, this reply is given to even insiders that don't want to deal with that obsolete shit.
> Citation please.
https://lkml.org/lkml/2020/5/28/1457
Here. Linus shut him down nicely though. :)
You need to be more specific about what you're referring to when you bring something up. I already stated that email clients can be set to use longer line lengths. Are you aware that the default line length for hard-wrapped emails is 72 characters, not 80? It shouldn't take 4 posts for you to be specific enough for one to get what you're referring to and then basically ignoring the point I already brought up pertaining to that issue.
> You're incorrect, it's a problem on wider screens as well
Given the level of nesting in this sub-thread, the large amount of blank screen space to the left of the post is not posing any issues in terms of readability. I'd rather avoid "embarrasing line wrap" due to hard wrapped lines that are too long for the display. Also, the format=flowed option has solved this issue.
> Again, that's an issue caused by non-HTML e-mail
I assume you're aware of the problems caused by HTML email where people end up getting phished because of the anchor element with the hfref property set to make the link look like a legitimate website like their bank? Email should be plain text only. Leave the HTML to the web browsers.
> That's not the issue, your network's QoS is bad.
If the QOS was bad, then email and IRC would not work. They still do on the slow downstream and upsstream connection. And even if your claim of QoS was true, that doesn't explain why I experience the same issue on my mobile with a GPRS connection.
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
At one time, I didn't know how it worked, but I read through the documentation (man pages for git, git format-patch, git send-email, and git am).
To be fair, when you create a new repo or fork a repo, Github will display the commands necessary to set your repository's origin or cloning the repository. It probably also tells you the commands necessary to push commits to the remote or pull from it.
There is documentation out there that gives you a general idea about how to submit patches, coding conventions, etc in [1]. It certainly would be nice if they added a short tl; dr section on how to configure git for using the format-patch and send-email commands (similar to what I did in my previous post).
> get told I didn't respect a half-dozen conventions (no HTML in emails, 80-char lines, format of the commits, the email subject and the cover letter, people CC'd...),
This is all documented in the SubmittingPatches file in the git repo itself in the Documentation directory. The maintainer and major contributors have to go through a lot of submitted patches and they, for better or worse, will apply a filter on what they accept. But reading through a text file to learn the conventions and requirements shouldn't be considered a barrier to entry.
> while quadruple-checking everything to make sure I don't send garbage on the mailing list and bother everybody,
The best way to do that is to test it against your own email account.
> I had to change my email client because it's basically impossible to respect these conventions or follow discussions without a specialised client à la Mutt,
A GUI client like Thunderbird would have worked for viewing threaded conversations and participating in them. In fact, there are a number of GUI email clients that support threaded view [2] (but would need to be configured to only send plaintext email). Submitting patches, on the other hand is best accomplished by using the format-patch and send-email commands since they ensure correct formatting. But the project could certainly do a better job documenting the actual set of commands and flags used for generating the patches and then submitting them (along with re-rolls). But the lack of concise documentation for the settings and workflow isn't something that makes the email workflow inferior or obsolete.
> then I get feedback fragmented over several emails instead of a single interface
The feedback is on a per commit basis. A patchset consisting of multiple commits can make for a large diff and make it more difficult to review (and require far more scrolling to view the diff and the comments in the Github conversation view). An email client with an index view of the commits along with their associated comment threads makes it easy to see which comments have been read or not, what you've replied to, etc.
> Which makes it a crazy high barrier to entry and feel old and obsolete. And maybe the high barrier to entry is considered a good thing by git/linux people, it's their right, but let's not pretend it doesn't exist
I guess the real argument comes down to whether reading documentation and reading through the mailing list before submitting a patch should be considered a high barrier for entry. Regardless of whether a project is managed via email, Github/Gitlab, or some other tool like Gerrit or Phabricator, there are always some conventions to follow in terms of code organization, style, commit message conventions, etc. At some point, one will have to learn by observing how things work from previous submissions and/or read through the documentation. There may be people who are willing to lead others through the process and show them what to do, but, that's not always the case.
I guess you could think of it as joining in a game that people are playing (soccer, basketball, poker, etc), but not knowing the rules. You could either read up on the rules beforehand and watch how they play before joining in or just start participating and learn as you play. But if you keep making mistakes and not respond to feedback, then others will be less inclined to work with you.
[1] https://github.com/git/git/tree/master/Documentation
[2] https://en.wikipedia.org/wiki/Comparison_of_email_clients#Ge...
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.
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...
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.
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.
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.
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.
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.
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.
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.
(I think this is a terrible idea, but also got me thinking if there's something interesting there)
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).
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.
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:
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.
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.
Plus I find that most of the time I just use the default patch view, not the side by side one when doing review.
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?
- Linus Torvolds
[1] https://github.com/torvalds/linux/pull/17#issuecomment-56611...
peaks and valleys between functions and such are a huge aid visually -- line wrapping makes visualization of source code harder for myself, personally.
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))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.
def f(
a,
b,
c,
d
):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.
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 may be imaging this, I dunno.
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.
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).
At least at work, I feel like my 80 column terminal is probably the only “reasonable” app as far as layout and readability go.
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.
[0] https://twitter.com/rob_pike/status/563801489190043648?s=21
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.
Keeping lines short also helps when pasting code to instant messengers or reading side-by-side git diffs.
80 seems good to me.
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.
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.
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?
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.
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.
Everytime someone tries to argue for it I want to suggest we swap their Mac for a Commodore 64...
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.
:-)
That is what he says
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.
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.
It is brain-dead, but that is exactly what is required in many styles.
[1] https://llvm.org/docs/CodingStandards.html#source-code-width
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`.