Live data from Hacker News

Is the 80 character line limit still relevant? (2008)

richarddingwall.name

21–30 of 180 posts

Re: Is the 80 character line limit still relevant? (2008)

#21
post #9

One minor advantage which wasn’t so relevant in 2008: 80 character lines are much easier to read on a smartphone. This is especially true for Safari on iOS, which always seems to make bad wrapping / sizing decisions with plain text. ETA: thinking back on it, several years ago I switched from 120 characters to 80 specifically because of this. I don’t have a car, so I read a lot of code on my phone while taking public…

Took me a second to realize ETA was "edited to add." I was very confused on what an estimated time of arrival meant, here. :) I'm surprised reading on a phone is common. Not at all something I would want to do. I'm assuming largely read only there? Makes me curious if the CWEB idea of styling specifically for reading has extra merit in that flow?

I've been reading books on phone since palm pilot and 160x160 screen.

I do not want to type / create on my phone though, certainly not code, or even sign up for stuff / submit / do applications on phone. Makes me a rarity though.

Re: Is the 80 character line limit still relevant? (2008)

#22
post #13

65-80 for readability however once you introduce indentation this naturally increases. I always felt that shorter lines were a good way to encourage less nested code. Alas after all these years the consensus is against me.

I still like 80 columns even on modern hardware and displays. It encourages me to keep my lines tidy and to break long lines apart. Sometimes I go a little over, but it's a nice target to reach for.

Re: Is the 80 character line limit still relevant? (2008)

#23

I use 120 or 132 (no idea why I picked that number), but I tend to break my lines well before that, especially on function signatures. I'm that git that puts each param on a separate line (so I can quickly comment them out when I need to). It annoys other programmers, but once I explain why ... They're still annoyed, but at least they're quiet about it.

> I'm that git that puts each param on a separate line

I do that too :)

Re: Is the 80 character line limit still relevant? (2008)

#24
I think the answer is pretty clearly "no, but" (or "yes, if"). Of course it depends on what you're doing – if you're writing shell scripts, it might make sense to keep them at 80 characters in case you have to go down to the data center and edit them from a terminal because your network card failed. But for most code, there's no particular limit that makes sense (in my opinion).

I'm somewhat against code formatting "rules" in general. If it's about readability (/aesthetics), different code will have different properties that make it readable or unreadable. Sometimes, forcing a line break makes code less readable. In other situations, it can have the opposite effect. IMHO, it's a local decision – and the human that's working on that code is better at deciding what's readable than a linter is.

Re: Is the 80 character line limit still relevant? (2008)

#27
post #9

One minor advantage which wasn’t so relevant in 2008: 80 character lines are much easier to read on a smartphone. This is especially true for Safari on iOS, which always seems to make bad wrapping / sizing decisions with plain text. ETA: thinking back on it, several years ago I switched from 120 characters to 80 specifically because of this. I don’t have a car, so I read a lot of code on my phone while taking public…

Took me a second to realize ETA was "edited to add." I was very confused on what an estimated time of arrival meant, here. :) I'm surprised reading on a phone is common. Not at all something I would want to do. I'm assuming largely read only there? Makes me curious if the CWEB idea of styling specifically for reading has extra merit in that flow?

I don’t know how “common” it is, but (like I said in my comment) the only reason I read code on my phone is that I am often on a bus or a subway. The comment about assuming I only read on my phone is bizarre: you are putting words in my mouth for reasons I do not understand. When it comes to books I like paper, and I usually read long PDFs on a tablet.

Re: Is the 80 character line limit still relevant? (2008)

#28
> formatting tennis

That's a paddling.

Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that.

(I hate tabs, but will never :retab someone else's code.)

My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything.

I would have serious reservations about any team member who wasted all our time on that.

Re: Is the 80 character line limit still relevant? (2008)

#29
post #9

Earlier quoted context omitted.

Took me a second to realize ETA was "edited to add." I was very confused on what an estimated time of arrival meant, here. :) I'm surprised reading on a phone is common. Not at all something I would want to do. I'm assuming largely read only there? Makes me curious if the CWEB idea of styling specifically for reading has extra merit in that flow?

I don’t know how “common” it is, but (like I said in my comment) the only reason I read code on my phone is that I am often on a bus or a subway. The comment about assuming I only read on my phone is bizarre: you are putting words in my mouth for reasons I do not understand. When it comes to books I like paper, and I usually read long PDFs on a tablet.

GP was not assuming you read only on the phone screen, but that you use phone just (only) for reading ("read-only") and not for editing.

Re: Is the 80 character line limit still relevant? (2008)

#30

> formatting tennis That's a paddling. Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that. (I hate tabs, but will never :retab someone else's code.) My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything. I would have serious reservations about any team…

I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.
Post reply on HN