Hacker News new | ask | show | jobs
by aithrowawaycomm 583 days ago
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 transit.

3 comments

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.

I've made edits to config files on the GitHub mobile app while on-call. Not something I like doing but I like having the option.
I have also done this on VTA (local train). It's very thrilling but not very high-bandwidth sort of thing. I haven't done it a lot. But I do read a fair amount of code on my phone, in blogs or whatever.
CWEB?
thanks!
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.
Sibling post is correct. I meant that as a question on if you edit while on the phone.
“read-only” might have removed the ambiguity there
Agreed. I'll blame my phone. :)

In seriousness, apologies on the confusion.

Someone else is going to be weird and want to look this up so I'll save you the trouble.

Yes, aithrowawaycomm's claim about line lengths are supported by many, many different sources who recommend a 50 to 80 character line length.

https://duckduckgo.com/?q=reading+optimal+line+length

IMHO, 80 characters is too narrow, especially with Python, for most coding tasks so I settle more around 100 (+-20) characters. PEP-8 says up to 99 characters is okay.

https://peps.python.org/pep-0008/#maximum-line-length

It's worth noting that most of those studies are for body text. To make that more directly applicable we should exclude indentation, but the additional punctuation (especially commas, but unfortunately no parentheses) also affects it.

Shading lines can also improve readability (this is known; the rest of this comment is speculation). It's probably not enough to simply alternating between e.g. white and off-white background, unlike for tables. More likely an alternation between 3 or 4 subtly-different colors is best; maybe these can form a pattern across additional lines (e.g. 121312321). If the difference isn't subtle enough, editing will suffer whenever you break the line count, but for reference only the human eye is pretty good at aligning subtle things. Maybe even an outright paper-texture background image? (This is more often a gimmick, but it can be useful.)

Why exclude indentation? A block of code that is indented say... 5 levels deep at 4 spaces is missing 20 columns. If that loss of space gives the developer discomfort, it sounds like a healthy reminder about complexity. Every level of nested scope is additional mental context of "global" state for a maintainer. There should be (reasonable) pressure on the author to refactor towards less indentation/nested scope.
It's an interesting point.

You can't have it both ways though - support hard line limits because the mere discomfort of long lines is insufficent to convince the programmer to refactor to something clearer, and then argue that the mere discomfort of the line limit including indentation should convince the programmer to refactor deeply nested code into something simpler. Which is it? Do we want to force limits with say a linter (80 characters of width max, 5 levels of nesting max) or let the programmer choose based on comfort?

I've had to implement things like an arbitrary-JSON formatter. Setting a fixed width including indentation doesn't work - there would always be (deeply nested) values you simply cannot print according to the rules (excluding, of course, strings which have their own difficulty). I kinda feel 80 characters excluding indentation works out ok in practice in a variety of settings.

Sure, excessive indentation is a code smell. But that doesn't impede the ability to read and track lines within a highly-indented block, which roughly follows the readability of prose and thus can use its numbers for comparison.

    > especially with Python
What is special about Python in this case?
On the other hand, horizontal scrolling on a touchscreen is more natural than with a mouse.
It's not, with a mouse I can scroll vertically with a Shift to scroll horizontally On a phone touch screen horizontal scrolling is also less ergonomic than vertical due to less range (and less ergonomic than vertical mouse), but I can't replace it