tags:

views:

2089

answers:

10

Why in this millenium should Python PEP-8 specify a maximum line length of 79 characters?

Pretty much every code editor under the sun can handle longer lines. What to do with wrapping should be the choice of the content consumer, not the responsibility of the content creator.

Are there any (legitimately) good reasons for adhering to 79 characters in this age?

+19  A: 

Keeping your code human readable not just machine readable. A lot of devices still can only show 80 characters at a time. Also it makes it easier for people with larger screens to multi-task by being able to set up multiple windows to be side by side.

Readability is also one of the reasons for enforced line indentation.

Justin Bozonier
Yes, granted. But why 79? Why not 100 or 120?Keeping things readable works both ways. Too much up-and-down reading of code is hard to grok too.
pcorcoran
It's true that a lot of devices can only show 80 characters. How many of them can't perform soft-wrapping?
Jim
Most Python-specific editors don't do soft word wrapping.
Chris Upchurch
Also, it is preferred to not have code wrap. From a user experience perspective, it's unacceptable for most.
Justin Bozonier
There are some operating systems like MVS which cannot handle lines longer than 72 characters. PEP-8 won't help here. Setting an arbitrary limit of 79 characters makes no sense since how characters per line are good depends on the editor, the monitor, the personal preferences of the user and so on.
codymanix
A: 

Since whitespace has semantic meaning in Python, some methods of word wrapping could produce incorrect or ambiguous results, so there needs to be some limit to avoid those situations. An 80 character line length has been standard since we were using teletypes, so 79 characters seems like a pretty safe choice.

Chris Upchurch
There's two different types of word-wrapping. There's hard-wrapping, where the lines are broken up with newlines, and there's soft-wrapping, where they are only *displayed* with breaks, but remain physically a single line. I don't see any problem with the latter.
Jim
Most Python editors don't do soft word wrapping because it produces ambiguous hard to read code in a language where whitespace and indentation is important.
Chris Upchurch
It doesn't produce ambiguous or hard-to-read code so long as the wrapping is visually identified somehow. Kate does this and it works fine. If an editor doesn't handle this, then that's a reason to file a bug against the editor, not a reason to impose a coding style that avoids the bug.
Jim
Even if it's indicated visually, it still makes the code much more difficult to read, which is why Python editors generally don't support it.
Chris Upchurch
Have you actually tried it for an extended period of time? I have. It doesn't make the code more difficult to read in my experience. Can you back up the claim that this is why Python editors don't include the feature? I've never heard that claim before.
Jim
+2  A: 

I agree with Justin. To elaborate, overly long lines of code are harder to read by humans and some people might have console widths that only accommodate 80 characters per line.

The style recommendation is there to ensure that the code you write can be read by as many people as possible on as many platforms as possible and as comfortably as possible.

Readonly
+5  A: 

I am a programmer who has to deal with a lot of code on a daily basis. Open source and what has been developed in house.

As a programmer, I find it useful to have many source files open at once, and often organise my desktop on my (widescreen) monitor so that two source files are side by side. I might be programming in both, or just reading one and programming in the other.

I find it dissatisfying and frustrating when one of those source files is >120 characters in width, because it means I can't comfortably fit a line of code on a line of screen. It upsets formatting to line wrap.

I say '120' because that's the level to which I would get annoyed at code being wider than. After that many characters, you should be splitting across lines for readability, let alone coding standards.

I write code with 80 columns in mind. This is just so that when I do leak over that boundary, it's not such a bad thing.

Jerub
+6  A: 

Printing a monospaced font at default sizes is (on A4 paper) 80 columns by 66 lines.

Josh
I accept this standard; it's valid. But who prints code any more? Moreover, who prints code from an environment which is intolerant of scaling or other formatting options? When was the last time anyone you know was stumped by their inability to render a line of 100 characters?
pcorcoran
+11  A: 

I believe those who study typography would tell you that 66 characters per a line is supposed to be the most readable width for length. Even so, if you need to debug a machine remotely over an ssh session, most terminals default to 80 characters, 79 just fits, trying to work with anything wider becomes a real pain in such a case. You would also be suprised by the number of developers using vim + screen as a day to day environment.

Sean O Donnell
<flame>Emacs FTW!</flame> +1, though. I think the 79 limit comes from the early days of UNIX (and possibly MULTICS) that had 80x25 character terminals.
Joe D
+4  A: 

79 characters (well, actually 72 characters) is where most text-based email readers linewrap. So code cut-and-pasted into an email is a lot more readable.

Joe Shaw
+5  A: 

because if you push it beyond the 80th column it means that either you are writing a very long and complex line of code that does too much (and so you should refactor), or that you indented too much (and so you should refactor).

Stefano Borini
A: 

Here's why I like the 80-character with: at work I use Vim and work on two files at a time on a monitor running at, I think, 1680x1040 (I can never remember). If the lines are any longer, I have trouble reading the files, even when using word wrap. Needless to say, I hate dealing with other people's code as they love long lines.

+6  A: 

Much of the value of PEP-8 is to stop people arguing about inconsequential formatting rules, and get on with writing good, consistently formatted code. Sure, no one really thinks that 79 is optimal, but there's no obvious gain in changing it to 99 or 119 or whatever your preferred line length is. I think the choices are these: follow the rule and find a worthwhile cause to battle for, or provide some data that demonstrates how readability and productivity vary with line length. The latter would be extremely interesting, and would have a good chance of changing people's minds I think.

Paul Hankin