Artificial limits to the line length is a mistake, it's a totally arbitrary value, and has horrendous knock on effects. People end up choosing bad variable names as otherwise the lines get too long. The intention was to produce readable code that can be viewed and understood, and if that is the intention, then line length should defer to readability, not the other way around.
8x16 font at 2560x1440 is 320 columns. Very easy to see, plus you can emulate old CGA/EGA/MCGA graphics with just space character and background color.
Meanwhile, for the last 500 years, people have been aware that narrow (newspaper style) columns are easy to read, and A4 (US letter) size paper with (approx) 80 12 point characters was the standard for readability long before the 80 column card was used for text.
I have a 4k screen for coding, but very few of my code files are bigger than 3 A4 pages of text
for readability, not because I used to maintain 3,000 card Fortran using an IBM 026 card punch.
Disclaimer: I did used to type set a hippy newspaper using an IBM Selectric typewriter in the 60s.
You're right, narrow columns improve readability. However, I believe the question we should consider is "is 'readability' in a newspaper and 'readability' in code defined in the same way?".
I think the answer is negative. For example, typefaces with serifs, ligatures and variable widths improve readability, but when it comes to programming - we prefer monospace fonts. Do newspapers come with "dark mode"?:-) Perhaps there are other differences too.
Code is not always read like prose. One could argue that the programmer operates in several modes, each at different levels of abstraction:
(a) high-level: "iterate over a list"
(b) low-level: "this is a for loop that begins at 0 and ends at X, and increments the counter with 1 at each step"
(b) is necessary when you're debugging it, but once the code was written and tested, subsequent reads of it can go at level (a).
For example, this Python chunk would be autoformatted by black ("the uncompromising code formatter"); note that you might have to zoom out a bit to make sure Slashdot doesn't add its own line breaks: for route_id, route_number, name in curs:
result[route_id] = Route(route_id, route_number, name)
result[route_id].stations = self.load_route_stations(route_id)
result[route_id].station_ids = [station.station_id for station in result[route_id].stations]
result[route_id].checkpoints = self.load_route_checkpoints(route_id)
result[route_id].checkpoint_ids = [entry.checkpoint_id for entry in result[route_id].checkpoints]
to:
for route_id, route_number, name in curs:
result[route_id] = Route(route_id, route_number, name)
result[route_id].stations = self.load_route_stations(route_id)
result[route_id].station_ids = [
station.station_id for station in result[route_id].stations
]
result[route_id].checkpoints = self.load_route_checkpoints(route_id)
result[route_id].checkpoint_ids = [
entry.checkpoint_id for entry in result[route_id].checkpoints
]
In the top code excerpt, the programmer sees it as "each line sets an attribute of the object in question", mode (a). Whereas in the bottom excerpt some of these logical operations span across multiple lines and you're forced into mode (b), because you're not sure if these several lines are a part of the same logical operation or not, until you read them.
This reminds me of the "Thinking fast and slow" dichotomy, where "system 1" makes a fast decision, while "system 2" makes a slow one. In my experience, quite often when long lines are broken down into multiple lines I am forced to deal with them using "system 2" when "system 1" would suffice.
So, there are cases when long lines are appropriate.
But they're close, and margin fiddling can make the line and page breaks work. Metric paper sizing is superior not because it's metric, but because of the 1:sqrt(2) ratio of width to height that means you can cut A1 in half and get two A2 sheets, cut them in half and get four A3 sheets, cut them in half and get eight A4 sheets, ad infinitum. Whereas letter and legal and our envelope sizing...
Sense at last (Score:5, Interesting)
Artificial limits to the line length is a mistake, it's a totally arbitrary value, and has horrendous knock on effects. People end up choosing bad variable names as otherwise the lines get too long. The intention was to produce readable code that can be viewed and understood, and if that is the intention, then line length should defer to readability, not the other way around.
Re: (Score:5, Funny)
Yes! Give me a hard limit of 80 character lines and I'll show you a bunch of 3-letter variable names!
A.
Re: (Score:3)
Re:Sense at last (Score:2)
8x16 font at 2560x1440 is 320 columns. Very easy to see, plus you can emulate old CGA/EGA/MCGA graphics with just space character and background color.
Re:Sense at last (Score:5, Interesting)
Possibly, in an Egyptian pyramid.
Meanwhile, for the last 500 years, people have been aware that narrow (newspaper style) columns are easy to read, and A4 (US letter) size paper with (approx) 80 12 point characters was the standard for readability long before the 80 column card was used for text.
I have a 4k screen for coding, but very few of my code files are bigger than 3 A4 pages of text for readability, not because I used to maintain 3,000 card Fortran using an IBM 026 card punch.
Disclaimer: I did used to type set a hippy newspaper using an IBM Selectric typewriter in the 60s.
Re:Sense at last (Score:5, Insightful)
You're right, narrow columns improve readability. However, I believe the question we should consider is "is 'readability' in a newspaper and 'readability' in code defined in the same way?".
I think the answer is negative. For example, typefaces with serifs, ligatures and variable widths improve readability, but when it comes to programming - we prefer monospace fonts. Do newspapers come with "dark mode"? :-) Perhaps there are other differences too.
Code is not always read like prose. One could argue that the programmer operates in several modes, each at different levels of abstraction:
(b) is necessary when you're debugging it, but once the code was written and tested, subsequent reads of it can go at level (a).
For example, this Python chunk would be autoformatted by black ("the uncompromising code formatter"); note that you might have to zoom out a bit to make sure Slashdot doesn't add its own line breaks:
for route_id, route_number, name in curs:
result[route_id] = Route(route_id, route_number, name)
result[route_id].stations = self.load_route_stations(route_id)
result[route_id].station_ids = [station.station_id for station in result[route_id].stations]
result[route_id].checkpoints = self.load_route_checkpoints(route_id)
result[route_id].checkpoint_ids = [entry.checkpoint_id for entry in result[route_id].checkpoints]
to:
for route_id, route_number, name in curs:
result[route_id] = Route(route_id, route_number, name)
result[route_id].stations = self.load_route_stations(route_id)
result[route_id].station_ids = [
station.station_id for station in result[route_id].stations
]
result[route_id].checkpoints = self.load_route_checkpoints(route_id)
result[route_id].checkpoint_ids = [
entry.checkpoint_id for entry in result[route_id].checkpoints
]
In the top code excerpt, the programmer sees it as "each line sets an attribute of the object in question", mode (a). Whereas in the bottom excerpt some of these logical operations span across multiple lines and you're forced into mode (b), because you're not sure if these several lines are a part of the same logical operation or not, until you read them.
This reminds me of the "Thinking fast and slow" dichotomy, where "system 1" makes a fast decision, while "system 2" makes a slow one. In my experience, quite often when long lines are broken down into multiple lines I am forced to deal with them using "system 2" when "system 1" would suffice.
So, there are cases when long lines are appropriate.
Re: (Score:2)
Actually length of lines makes no difference for me in "easy to read".
I never believed such claims or studies - but I never conducted a study, so no idea.
Re: (Score:2)
Not to be "that guy" but US Letter paper is not the same dimensions as A4.
US Letter: 8.5 by 11 inches (approx. 21.5 cm by 27.9 cm)
A4 paper: approx. 8.27 inches by 11.75 inches (21 cm by 29.7 cm)
Re: (Score:2)
Re: (Score:2)
8x16 font at 2560x1440 is 320 columns. Very easy to see
What a truly bizarre claim, as if raw pixel sizes had any bearing on visibility.