The recommended line length in Black is 88 characters.
I’ve participated in a few code standardization processes. By and large I’m an enormous fan: I read a lot of code and am helped by the consistency they promote. Python has particularly been kind to me here with pycodestyle and pylint.
The thing I’ve learned from them though is that I’m the last person on the planet (or at least the three companies I’ve had a hand in standardizing) that still uses an 80-character terminal to code. It’s the one thing I have a (literal) hard line on. I note the nature of the problem often doesn’t get through and so I’m offered compromises that are as equally bad as to the original. I don’t think I’ve ever been offered “how about 88 characters” but I have worked with folk who themselves tell me they won’t tolerate anything less than 100+ but try to talk us somewhere between 81 and 99 characters.
I’m a fan of short lines, but this is a pretty bad argument. What is The Terminal? Even without running a GUI like X11, you can get higher resolutions in framebuffer or whatever it’s called.
IMO, the compelling argument for me for shorter lines is readability. I just can’t read long lines, I got lost and confuse by the end. I like reading down than across.
I had it put to me that code review is significantly easier with an 80 character limit. My worst case is working on my laptop (in terms of screen size), and I get 84 characters across in vimdiff before ‘running out of screen’.
The terminal is a VT100, with support for an 80x24 display. The 80 character limit was present before then, however, via the 80-character punched card. Those having 12 lines rather than 24.
It is marvelous that we have a display technology backward compatible with the entire history of computing.
I’m not sure I get your argument, though. Because old tech had a width of 80 characters, we should now? Old tech had a clock rate of 100 Mhz and little storage, but I doubt you’d argue we should be using machines with those specs. And the truth is: almost nobody is programming in a VT100 terminal today. So are you making a luddite argument for line length or is there an actual benefit to 80 characters?
I’m saying that if you have to choose a line length, in a standard, that 80 characters is the choice we already made. As a consequence of that choice, 88 characters is two lines. That if your choice is 80 characters or 88 characters, 80 characters has a superior and sufficient claim to be a standard.
It is true that terminal emulators will emulate a display larger than 80 characters. I’m a fan of the -S flag to less when I’d like my input file to tell me how wide my display should be. I also routinely work with two terminals side-by-side on a graphical display. Both modes of working are fantastic. The later is enabled by a standard line length of 80 columns. When my terminal has an 81st column, I’m using that column. It’s not available for use by the standard.
So is there any way to standardize on lines longer than 80 characters or is this it for eternity/the rest of our natural lives? What would be a compelling argument for longer lines, for you?
The other area where the question of line length comes up is typography. There, line length is measured by words rather than characters owing to the proportional spacing of characters in a font. If I was dealing with source code in a typographic context the conventions of that field would also apply–possibly to the exclusion of monospace font conventions, possibly in combination with monospace font conventions, depending on how the code is typeset.
You’re missing my point, I’m not saying we should change it just to change it, I’m asking why a decision made 50 years ago still applies today. If long lines are uncomfortable to read, that is at least an argument that would still apply today and not simply the momentum of history.
I’ve participated in a few code standardization processes. By and large I’m an enormous fan: I read a lot of code and am helped by the consistency they promote. Python has particularly been kind to me here with pycodestyle and pylint.
The thing I’ve learned from them though is that I’m the last person on the planet (or at least the three companies I’ve had a hand in standardizing) that still uses an 80-character terminal to code. It’s the one thing I have a (literal) hard line on. I note the nature of the problem often doesn’t get through and so I’m offered compromises that are as equally bad as to the original. I don’t think I’ve ever been offered “how about 88 characters” but I have worked with folk who themselves tell me they won’t tolerate anything less than 100+ but try to talk us somewhere between 81 and 99 characters.
The terminal is 80 characters wide.
I’m a fan of short lines, but this is a pretty bad argument. What is The Terminal? Even without running a GUI like X11, you can get higher resolutions in framebuffer or whatever it’s called.
IMO, the compelling argument for me for shorter lines is readability. I just can’t read long lines, I got lost and confuse by the end. I like reading down than across.
I had it put to me that code review is significantly easier with an 80 character limit. My worst case is working on my laptop (in terms of screen size), and I get 84 characters across in vimdiff before ‘running out of screen’.
The terminal is a VT100, with support for an 80x24 display. The 80 character limit was present before then, however, via the 80-character punched card. Those having 12 lines rather than 24.
It is marvelous that we have a display technology backward compatible with the entire history of computing.
I’m not sure I get your argument, though. Because old tech had a width of 80 characters, we should now? Old tech had a clock rate of 100 Mhz and little storage, but I doubt you’d argue we should be using machines with those specs. And the truth is: almost nobody is programming in a VT100 terminal today. So are you making a luddite argument for line length or is there an actual benefit to 80 characters?
Long story short, lines are limited to 80 characters because Roman roads were designed for chariots drawn by two horses, side-by-side.
I’m saying that if you have to choose a line length, in a standard, that 80 characters is the choice we already made. As a consequence of that choice, 88 characters is two lines. That if your choice is 80 characters or 88 characters, 80 characters has a superior and sufficient claim to be a standard.
Pep 8: Limit all lines to a maximum of 79 characters.
OpenBSD mailing list netiquette: Plain text, 72 characters per line
It is true that terminal emulators will emulate a display larger than 80 characters. I’m a fan of the -S flag to less when I’d like my input file to tell me how wide my display should be. I also routinely work with two terminals side-by-side on a graphical display. Both modes of working are fantastic. The later is enabled by a standard line length of 80 columns. When my terminal has an 81st column, I’m using that column. It’s not available for use by the standard.
So is there any way to standardize on lines longer than 80 characters or is this it for eternity/the rest of our natural lives? What would be a compelling argument for longer lines, for you?
The other area where the question of line length comes up is typography. There, line length is measured by words rather than characters owing to the proportional spacing of characters in a font. If I was dealing with source code in a typographic context the conventions of that field would also apply–possibly to the exclusion of monospace font conventions, possibly in combination with monospace font conventions, depending on how the code is typeset.
Why would we change the standard to longer lines? They are more uncomfortable to read anyway.
You’re missing my point, I’m not saying we should change it just to change it, I’m asking why a decision made 50 years ago still applies today. If long lines are uncomfortable to read, that is at least an argument that would still apply today and not simply the momentum of history.
You are not alone! Some of us are still guarding the purity of 79 characters wide code
Isn’t the
fmt: offannotation pretty compromising?