321–330 of 330 posts
80 seems good to me.
Earlier quoted context omitted.
> How? That workflow assumes a 80-char b/w terminal for the most part. There's nothing stopping you from using a gui text editor to edit the code and there's nothing in git commits or the code itself that forces wrapping at 80 characters. Email clients certainly can wrap text at longer line lengths if configured to do so. > Try using any part of it on mobile or with large font size due to bad eyesight, it's awful. I…
> there's nothing in git commits or the code itself that forces wrapping at 80 characters Very clever leaving out the third component here that does force it. > Email clients certainly can wrap text at longer line lengths if configured to do so. Assuming someone hasn't banally pre hard-wrapped the text. > I don't try to do any serious development on my mobile. Who said anything about serious development, you basicall…
> 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.
Earlier quoted context omitted.
> there's nothing in git commits or the code itself that forces wrapping at 80 characters Very clever leaving out the third component here that does force it. > Email clients certainly can wrap text at longer line lengths if configured to do so. Assuming someone hasn't banally pre hard-wrapped the text. > I don't try to do any serious development on my mobile. Who said anything about serious development, you basicall…
>> there's nothing in git commits or the code itself that forces wrapping at 80 characters > Very clever leaving out the third component here that does force it. Which component is that? The SMTP protocol? According to [1], the maximum line length allowed by SMTP is 1000 octets, which is well over any maximum hard-wrapped line length for typical source code lines. > Assuming someone hasn't banally pre hard-wrapped th…
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. :)
Earlier quoted context omitted.
>> there's nothing in git commits or the code itself that forces wrapping at 80 characters > Very clever leaving out the third component here that does force it. Which component is that? The SMTP protocol? According to [1], the maximum line length allowed by SMTP is 1000 octets, which is well over any maximum hard-wrapped line length for typical source code lines. > Assuming someone hasn't banally pre hard-wrapped th…
> Which component is that? The SMTP protocol? According to [1], the maximum line length allowed by SMTP is 1000 octets, which is well over any maximum hard-wrapped line length for typical source code lines. The wetware component enforcing some line length - some old maintainer stuck in his ways. I don't see what you're trying to achieve ignoring that? > Hardwrapped text is only a problem for displays that cannot disp…
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.
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…
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 abo…
Earlier quoted context omitted.
> 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 h…
> 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.
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.
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.
Earlier quoted context omitted.
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 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|