> Further, the only sensible screen width is 80 characters, since that also works everywhere.
I'm curious. Where does 80 characters not work now? How many people / industries are still using green-screen terminals with a fixed-width of 80 characters?
I'm generally in favour of enforcing line-wrapping requirements, because I've worked with people that would have a tendency to write code that trails off the end of the earth if you let them. But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done."
I realize that the 80-character limit is "everywhere"[1], but other than "it's everywhere" is there a more solid reason?
[1] When editing text emails in Vim the default textwidth value is 72, so that there is still some flex for quoting explicitly wrapped text (i.e. prepending "> " to the lines) and staying within the 80-character limit. The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters. etc...
80 character line wrapping is IMO more important on larger and wider-aspect ratio screens. Even the smallest 16:9 aspect ratio screen can be split into two columns, one being an 80 character column for code and the other left wide for a web browser or document viewer (this is now my setup when working on 16:9 aspect ratio laptops).
I see a lot of people work on large displays and with multi-monitor setups. Those who do not have their screens split into an 80-character or similar terminal and text editor width columns spend a lot of time switching between screens or applications. Couple this with the fact that you have to move your eyes around a lot on larger displays (and even head, in the case of multi-monitor set ups) and their setups actually make them navigate slower than they would on a smaller display.
> But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done."
Having shorter lines makes reading diffs easier (whether it's unified, context, or split diffs).
> The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters.
It's actually 72 characters for the commit message body for a similar reason that you mentioned for emails. Specifically, it's because the git log output indents the commit message relative to the diff (when using the -p option).
> Having shorter lines makes reading diffs easier (whether it's unified, context, or split diffs).
But is the difference that significant between 80-, 100- and (say) 120-characters wide? I personally wrap at 100 characters, I don't find that I'm fatigued by looking at diffs of the code.
It is subjective to some extent, but I do find that those who don't wrap their code at 80 characters aren't really particular in terms of wrapping their code at all. So most lines may be between 70 to 130 characters, but there may be the occasional line that's a bit longer.
Plus, it also depends on the tools one uses to review code. Github, for instance, will present a horizontal scroll bar for the unified diff view if there are lines that are too long. Using that scroll bar is not something I appreciate having to do when reviewing code.
Further, given that you're dealing with a language that uses significant indentation, you end up having to use stupid tricks that make your code less readable to stay under the bar.
Indented two levels (an 'if' block in a function in a class) and a couple of interpolated variables in an error message isn't unreasonable to have on a single line.
I know that it has to do with the width of older terminals, perhaps even back to the teletypes. But those hard restrictions don't exist anymore, yet some people treat "80 characters" as some golden law passed down from heaven that cannot be broken lest you incites the wrath of the gods. That kind of fervour (without some sort of concrete, logical reasoning) is nothing but cargo-cultism so far as I'm concerned. E.g. "we do it this way because it's always been done this way."
Just because it originates from teletypes that are no longer used doesn't mean that there's a problem with that width today. We need some standard, because otherwise you end up in formatting hell. There's nothing wrong with 80, so it might as well continue to be 80.
I'm curious. Where does 80 characters not work now? How many people / industries are still using green-screen terminals with a fixed-width of 80 characters?
I'm generally in favour of enforcing line-wrapping requirements, because I've worked with people that would have a tendency to write code that trails off the end of the earth if you let them. But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done."
I realize that the 80-character limit is "everywhere"[1], but other than "it's everywhere" is there a more solid reason?
[1] When editing text emails in Vim the default textwidth value is 72, so that there is still some flex for quoting explicitly wrapped text (i.e. prepending "> " to the lines) and staying within the 80-character limit. The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters. etc...