256

Why in this millennium 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?

wjandrea
  • 16,334
  • 5
  • 30
  • 53
pcorcoran
  • 7,146
  • 6
  • 26
  • 26
  • 78
    The answer to your question is *in* PEP-8. – cdleary Dec 31 '08 at 21:03
  • 32
    Shorter line lengths enhance productivity by increasing your KLOC. :p – Alex Mar 02 '13 at 01:00
  • 13
    Don't you people use side-by-side diff tools? – endolith Mar 03 '16 at 01:49
  • 2
    Today i started to use monitor in portrait and this pep is quite helpful to see full text. – qwerty Apr 01 '16 at 10:23
  • 7
    For those who go as far back as punch cards, punch cards were 80 columns in width (https://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era). That value was then adopted by dumb ASCII terminals. And then propagated into other "standards"... – RBV Nov 11 '16 at 22:59
  • Leading python core developer recommends 90ish https://youtu.be/wf-BqAjZb8M?t=260 (Black formats at 88) – Chris_Rands Jun 01 '19 at 19:39
  • @Jonathan The author of the linked Nova package definitely loves splitting the code line over multiple lines. It is very uncomfortable to read such code for me. – Jeyekomon Jun 10 '19 at 08:48
  • 2
    Black formats at 120 if you tell it to. I do. PEP-8 also says **"it is okay to increase the line length limit up to 99 characters"** but people seem to suppress that information much of the time. – NeilG Jul 26 '19 at 00:18
  • How you dare to question bad practices and vices of the "seniors" who still live in the CRT age? – Pablo Ariel Sep 05 '19 at 22:52
  • 1
    @cdleary Yup, it's been revised a bit over the years but currently says "Limiting the [...] width makes it possible to have several files open side-by-side, and works well when using code review tools that present the two versions in adjacent columns.The default wrapping in most tools disrupts the visual structure of the code, making it more difficult to understand. [...] Some web based tools may not offer dynamic line wrapping at all." – wjandrea Jun 25 '20 at 17:01
  • @PeterSmit Seems to be here now: https://github.com/openstack/nova/blob/master/nova/manager.py – wjandrea Jun 25 '20 at 17:03

9 Answers9

140

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.

  • 30
    Most reading studies are done in inches and not characters per line. The 66 character rule is based on studies done for reading newspapers. [Recent studies](http://www.usability.gov/articles/newsletter/pubs/082006news.html) have shown that when reading online articles, reading speed increases up to about 120 characters per line (10 inches at size 12 font) with no loss in comprehension. – Pace Mar 29 '13 at 21:14
  • 7
    Actually everybody who read into that topic *thinks* that 79 characters is optimal. That's why it was added to PEP8! This answer is actually wrong. [This one is the correct one](http://stackoverflow.com/a/88948/131120) – erikbwork Apr 29 '13 at 11:24
  • 6
    I thought the question is about why 79 is better than 80 or 78 – n611x007 Dec 12 '14 at 15:39
  • 2
    The biggest problem I have with this is that I, like nearly all programmers I know, use the same terminal for editing code and running code. If you set your terminal to be 80ish wide so you have room for other things on your monitor, when you run your code, your stacktraces and log files are unreadable. This causes you to use a wider terminal. Therefore, your text editor is wasting space. Why not use separate terminals? Sometimes we do, but for 95% of cases 1 terminal window with 1 tmux inside is the optimal "get out of my way and let me code". – Bruno Bronosky Mar 05 '15 at 18:05
  • 195
    `there's no obvious gain in changing it to 99 or 119 or whatever your preferred line length is` This is just so wrong in so many ways. Wrap a line at 40 characters and tell me how readable it is. Obviously less wrapping = more readability so long as you have the screen space, which in 2015, you do. Wrapping impacts readability. Readability impacts maintainability. Maintainability impacts quality. And quality is impacted if you're wrapping at 80 chars. Full stop. – Jonathan Jul 09 '15 at 00:53
  • @Pace. The "Recent studies" link is broken. Can you provide a refreshed version? – Josiah Yoder Sep 21 '16 at 19:10
  • 2
    @JosiahYoder: If you search for "line length" at the given link, you'll get a list of matches. The first one I got was to an article titled [_Reading Onscreen: The Effects of Line Length on Performance_](https://www.usability.gov/get-involved/blog/2006/08/line-length-and-onscreen-reading.html) which says 95 characters per line was the best in a 2005 study (which was the longest they tested). The usability study itself is available [here](http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp). Notably, the study participants _weren't_ reading computer code. – martineau Jun 14 '17 at 14:21
  • 10
    Arguing about readability with anything non-code is useless as those studies assume running text. Code looks completely different with different (character) line length every line. And even if you write till the end of the line, indentation changes the amount of characters per line. – Corvince Nov 07 '17 at 12:46
  • 1
    Also my vt52 terminal is only 80 characters. – Gadi Nov 20 '17 at 21:01
  • 2
    PEP-8 also says **"it is okay to increase the line length limit up to 99 characters"** but people seem to suppress that information much of the time. – NeilG Jul 26 '19 at 00:22
  • 4
    `This is just so wrong in so many ways. Wrap a line at 40 characters and tell me how readable it is. Obviously less wrapping = more readability so long as you have the screen space... And quality is impacted if you're wrapping at 80 chars. Full stop.` Don't be dramatic. This _may_ be wrong in exactly one way. Also, you make a strong claim with lots of confidence while providing no evidence. I could also claim that even if you have the screen space, a 200 or 300 character line is not as readable. Full stop. :p – gwg Aug 16 '19 at 10:43
  • PEP8 Was written by people who still write code with CRT screens. But, it's ok if competitors love to spend their day scrolling in order to see only fragments of code for functionality that could be seen on-screen. It's also an advatage that this causes them to miss a lot of context facilitating bugs. I love it and I use them to sell my work, as "the ones you wouldn't buy from". – Pablo Ariel Sep 04 '19 at 19:17
  • Heh... In 2019 I finally read PEP-8 and had the same question. Actually about code line length in general (why some people like to hard-wrap so tightly). Sure 40 years ago coding on a TV screen with 40 chars and printing out reams of paper just to see it all was fun... but c'mon. Dunno about you guys but these days I don't feel efficient unless I have my 4 widescreen monitors in various orientations. :) Though I always liked 4:3 better for "real" computer use (i.e. not watching movies). – Maxim Paperno Oct 10 '19 at 08:34
119

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
  • 7,154
  • 9
  • 42
  • 46
  • 65
    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 Sep 18 '08 at 00:39
  • 19
    It's true that a lot of devices can only show 80 characters. How many of them can't perform soft-wrapping? – Jim Sep 18 '08 at 00:44
  • Most Python-specific editors don't do soft word wrapping. – Chris Upchurch Sep 18 '08 at 01:04
  • 39
    Also, it is preferred to not have code wrap. From a user experience perspective, it's unacceptable for most. – Justin Bozonier Sep 18 '08 at 07:00
  • 8
    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 Apr 20 '10 at 14:53
  • 7
    79 comes from the days of dot matrix printers, they only printed 80 characters per line. Today we all sit with 16:9 ratio displays with a lot of width and limited vertical space... I follow every rule in PEP8 except this one, I believe it should be brought in line with current technology. – Gert Steyn Dec 03 '13 at 14:00
  • 112
    79 characters also makes programmers use shorter more cryptic variable and function names to make everything fit. This is bad for readability. – Gert Steyn Dec 03 '13 at 14:01
  • 1
    why is 80-1 any better than 80-0 or 80-2? – n611x007 Dec 12 '14 at 15:42
  • 6
    @GertSteyn `Today we all sit` don't underestimate coding over ssh beside a stand with no chairs on an oldschool 4:3. – n611x007 Dec 12 '14 at 15:43
  • 5
    @Jonathan I have a set up with a vertical monitor with a large font (so I can sit further away from the monitor) and often split my editor windows so I can work on multiple files at once. The line length restrictions really improve my readability. – Ian Hunter May 22 '15 at 17:02
  • 1
    `Readability is also one of the reasons for enforced line indentation` Agreed, but forced line wrapping makes code less readable. – Jonathan Jul 09 '15 at 01:05
  • 1
    80 characters is the max number of characters you can read without moving too much your eyes left and right, at console font. So you can easily scroll up and down and read everything. – Nic Szerman Sep 19 '20 at 13:36
49

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
  • 38,558
  • 14
  • 69
  • 90
  • 14
    "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." Same for me. – KobeJohn Nov 04 '11 at 06:27
  • 4
    10 years later: Doesn't that just depend on how you set up line wrapping. Line wrapping can be as intelligent or stupid as you want it. If it's uncomfortable to read that's just a failure of your editor. – David Mulder Sep 10 '18 at 13:34
  • 3
    I code to 120 chars but occasionally longer when it suits readability. Black formats at 120 if you tell it to. PEP-8 also says **"it is okay to increase the line length limit up to 99 characters"** but people seem to suppress that information much of the time. Almost no-one uses terminals that are 80 wide. Log messages are never 80 wide. – NeilG Jul 26 '19 at 00:25
39

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
  • 1,225
  • 1
  • 11
  • 11
  • Emacs FTW! +1, though. I think the 79 limit comes from the early days of UNIX (and possibly MULTICS) that had 80x25 character terminals. – Joe D Sep 10 '10 at 13:55
  • 10
    My ssh+screen+vim environemnts have no problem displaying long lines. – chrishiestand Apr 30 '12 at 21:07
  • 55
    "66 characters per a line is supposed to be the most readable width for length" I suppose we should write code in 2 or 3 columns, since that's how newspapers are laid out? – Mark E. Haase Dec 16 '12 at 16:37
  • 24
    @mehaase: your sarcastic remark is quite close to the truth: decent editors can do split panes and show different stuff side-by-side (from same or different files). Coincidentally, this is usually only feasible when the code has a line-length standard... – mike3996 Oct 21 '15 at 12:57
17

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

Josh
  • 7,586
  • 5
  • 36
  • 60
  • 12
    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 Sep 18 '08 at 04:04
  • 4
    Why do people print code in 2012? This reminds me of going to a technology conference and being handed a bag and a printed binder full of presentations. It's the 21st century people: e-mail me the slides or else that bag and binder are going straight into a landfill. – Mark E. Haase Dec 16 '12 at 17:03
  • 2
    so why 80-1 is better than 80-0 or 80-2? – n611x007 Dec 12 '14 at 15:41
  • 14
    "at default sizes" You say? Tell me more about these universally accepted default sizes. – Bruno Bronosky Mar 05 '15 at 17:54
  • 18
    Yes, let's prioritize the way that code looks on printed paper above all else. – Jonathan Jul 09 '15 at 00:59
11

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.

  • don't you use vim for javascript/html as well? – elad silver Apr 20 '18 at 15:45
  • 2
    @eladsilver I can't work out if that is a joke? :-D – Steven Church Aug 24 '18 at 08:39
  • sorry, not very profound with vim, obviously if you work in web you use it also for html/js and those types never come with a 80 char limit since front end developers don't know about pep8, so making python limit 80-char won't solve your problem if you use more then only python. so what I am asking is how do you handle other coding languages? – elad silver Aug 24 '18 at 20:00
  • I work in Vim with 120 character lines. I use :diffthis with horizontal split. If you can only fit 160 chars on 1680 pixels you must have a large font size. – NeilG Jul 26 '19 at 00:26
5

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
  • 14,377
  • 6
  • 48
  • 66
  • 4
    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 Sep 18 '08 at 01:03
  • 4
    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 Sep 18 '08 at 01:14
  • 5
    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 Sep 18 '08 at 01:16
  • 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 Sep 18 '08 at 01:43
2

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
  • 306,152
  • 101
  • 198
  • 201
  • 10
    This is a lazy argument. It is not always the case that 80 lines harms readability. A quick glance at any modestly complex Python codebase that wraps at 80 lines actually demonstrates the opposite - that wrapping single line function calls to several lines makes it harder to follow WTF is going on. – Jonathan Mar 14 '15 at 00:46
-1

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
  • 125,999
  • 87
  • 277
  • 404
  • 96
    -1, I don't think you can categorically say that any line past the 80 char boundary requires a refactor. Class methods are already indented twice, add another indent for an "if", etc. and a simple list comprehension, and it's pretty easy to cross the 80-char boundary. –  Apr 04 '11 at 19:17
  • 47
    Not to mention that if you name symbols in such a way that they are human readable, e.g. "users_directed_graph" instead of "usr_dir_gph", then even a simple expresswion will eat up quite a few characters per line. – Mark E. Haase Dec 16 '12 at 16:43
  • 8
    I have always found in Python that if I exceed 80 chars its wise to stop and think about why that is. Usually bad design decision is at fault. – Mike Vella Aug 10 '13 at 00:44
  • 3
    This has been my experience as well. It also addresses longer variable names, as @mehaase points out, but I think this is a benefit. The available combinations of three consecutive words (in the case of "users_directed_graph") dwarfs the number of components that reasonably fit into a single namespace. I consider older code I've written where many similar long variable names are in the same namespace to be harder to read, and generally better to refactor. – TimClifford Nov 26 '14 at 17:25
  • 4
    In a language that requires indents for each change of scope, saying that 80 character lines equates to complexity is an overly simplistic argument. Sometimes 80 characters is just what it takes to invoke a function. Modern IDE's/editors for other languages are smart enough to recognize this and can discern when to wrap as opposed to placing blanket restrictions on everything which harms readability overall. – Jonathan Mar 14 '15 at 00:42
  • This is severely misguided. It is a good reason to give pause when code exceeds 79 characters but it doesn't not necessarily mean it is too long and complex nor require refactorization. – edwinksl Jul 30 '16 at 17:38
  • If I recall, the original reason behind the 79 chars was due in part by old school computers / command prompt / command line only having a 79 character length. The moment that you went beyond the number of characters, you formed a new line and thus made it unreadable. That's not the case anymore, it just looks nicer. – SirJames Feb 08 '17 at 14:58