I am completely blind in one eye and partially blind in the other. With the remaining eye, I have no peripheral vision in certain directions. My field of vision is narrower than that of normal people. I cannot see the entire screen, and when I focus on a line, I cannot see the ends of it and the lines above it.
When you read, you scan a line word by word, and when you get to the end of a line, you jump to the beginning of the next line. You can do this because you see the beginning of the line and the adjacent lines in your peripheral vision. For me, that’s a problem. And the longer the line, the bigger the problem.
Also, because there is so little left of my eye, and I was already nearsighted, I have other low vision problems. I need to increase the font size, so even with the 80 column limit, some lines are wrapped in a 2-side diff view.
Of course, my circumstances are rare — one in a million — and it’s not worth tailoring the code style guide to fit me. But there are people with other visual impairments, and even people with perfect vision find it easier to read when the line length is limited. In fact, it’s common practice in scientific journals to format text in two columns.
I suspect the reason line lengths should not be too long is related to how we read—by moving our eyes. There’s a reason newspapers have columns and books are not A4 or US Letter width. I just checked on substack.com and medium.com and the number of characters per line in their articles is around 65 and 75 respectively (may depend on settings I guess).
There’s probably some science I don’t know about but I’m guessing it’s to do with how far our eyes have to move left-to-right and especially returning from the end of one line to the start of another.
Also, older people like me have to increase font size so that reduces the possible length.
Having said that, your point about Python’s indenting does suggest that the limit should apply from the first character of a line to the end. I would support that.
Funny enough as a stepping stone to get there, we would need a formatter for the stdlib that was universally applied. I don’t think we have that piece yet.
Would be kind of cool if we ran ruff or similar against the stdlib.
I didn’t make it clear why I posted the link to that line of code, and only later clarified what I meant with this response:
In other words, I think the line is fine as-is to me when viewed with a viewer set for a 99-character line length, and with its 62-character effective line length starting from its first printable character I can still easily find the start of the next line.
But due to the need for side-by-side diff views and for people with reduced vision I’m no longer in support of this proposal either.
You might have problems when one uses non-standard formatting to emphasise aspects of the algorithm or to follow an external spec.
Here’s an example from the Shoelace formula for calculating the area of polygons where extra spacings are used to align contrasting parts of the equation:
def area_by_shoelace(x, y):
"Assumes x,y points go around the polygon in one direction"
return abs( sum(i * j for i, j in zip(x, y[1:])) + x[-1] * y[0]
-sum(i * j for i, j in zip(x[1:], y )) - x[0] * y[-1]
) / 2
I’ve been working with Trent. Trent is legally blind, but he’s a programmer and he’s been my coworker for some years.
When he looks at code, he stares at the screen from about 8 inches, and the letters are 3/4 inch tall. So he’s effectively got about 80x20 letters on his 27 inch screen. He really hates it when code is wider than 80 characters. Ever since I’ve seen how Trent struggles, I’ve been making sure Trent can read my code. So 80 characters it is. It’s not always convenient, but if it makes collaboration better with more people.
`Can’t help but feel humbled by some people not asking for less than 80, just quitely accepting the current norm of 80 as what must be their compromise.
I love Pythons community.
This is me who wrote those lines. At that time, I think my settings were for a 95-chars wide and I probably missed the fact that I was actually above 80 chars. Note that the comments are actually interestingly wrapped to 80 chars.
Strictly speaking, I could have removed 1 or 2 indentation levels and avoid match statements, but I probably assumed that the current writing was cleaner from a control-flow PoV. For instance, I could have swapped the ifs and use continue to remove indentation levels, or refactor the method, but I didn’t think it was worth it (the method is barely used).
If I can absolve myself of this PEP-8 violation, the function is going to be removed in Python 3.16! (also it was one of my first contributions).
I’m not an expert in typography so I don’t know the history, but simply saying “it’s called typography” is not an answer to the question of what research black did to come to the 88 character number. If you are an expert in typography and can quote authoritative sources of why 88-ish characters is the sweetspot I’d be happy to read them.
To my understanding, typography through the last centuries (probably millenia since many of the traditions likely go back to scribes) is a valance act between aesthetics, readability, and cost, where cost has been the major driver of typographic decisions.
I remember when I was a kid (mid 2000s) when I was taught that serif fonts were superior to sans serif fonts, but then Microsoft switched the default from Times to Calibri and I think that clearly debunked that claim.
According to this research, serif fonts are more legible at very small sizes, but that it largely due to the increase in letter spacing that serif fonts provide.
I think MS decision is more around the “friendliness” of sans-serif fonts.
