10

I think every Python code has seen PEP 8. The part that sticks out to me is:

Limit all lines to a maximum of 79 characters.

I'm sitting here on a widescreen monitor and coding right across the screen. I'm not coding in a terminal and don't plan on coding in a terminal. I therefor have no problems with character-line limits.

How many people actually follow this limit? Do you still follow it if you're not coding in a 80 character limit terminal? Is it bad that I don't follow it?

I hate how this restriction is apart of 'the style guide' for Python >.<

dave
  • 7,717
  • 19
  • 68
  • 100
  • 1
    http://stackoverflow.com/questions/3955903#3956014 – Glenn Maynard Oct 25 '10 at 07:15
  • 3
    I like non-super-long lines, but 79 characters is too low (esp. with today's focus on screens that are twice as wide as they are tall). It also can create unreadable code itself, so I'd say come to an agreement with the other people you work with and work with that. I tend to work with around 132 characters. – Nick Bastin Oct 25 '10 at 07:23
  • 2
    Pretty much the only time it matters is when you're using Putty on Windows and the braindead 80-char wide terminal. Or, editing in Nano without word wrap. Does this matter, though? Not really. Note that PEP 8 was originally written in 2001. – JAL Oct 25 '10 at 08:02
  • @JAL - PuTTy doesn't have an 80-char limit that I know of. I set my PuTTy sessions to 178 chars. – Andrew Cheong May 26 '14 at 19:55

9 Answers9

11

PEP 8:

But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment.

remosu
  • 5,039
  • 1
  • 23
  • 16
10

Are you the only one who's going to read the code?

No matter what language you're programming in, it's recommended practice to keep code line length down. There are typically 2 types of causes for long lines:

  1. Deeply nested code: this type of code is hard to follow, especially if you have more than 2 levels of nesting. There is a tendency to miss else clauses when reading the code, or forgetting which else is for what if when reading longer functions. Try to break the code in several functions to improve readability.

  2. Complex expressions: like when you access a value from an object from an object from an object ... Or when you need to do a single operation on multiple values from 10 different places and you merge all the function calls and operators in a single line. You'll significantly improve the readability if you use temporary variables to split the logic into smaller segments that are easier to grasp. You should also look into this.

That being said, that PEP is just a guideline. Feel free to break it when you feel you're justified to do so. If you break it most of the time you need to reconsider the way you write code.

Mihai Damian
  • 11,193
  • 11
  • 59
  • 81
  • Breaking things into smaller functions is another very helpful technique. That includes using a series of generator expressions. Generator expressions can also be nicely spread out over a couple of lines — I usually line the `if` up with the `for`. – intuited Oct 25 '10 at 09:53
4

I find it hard to read text that spans over 80 characters. My eye tends to lose the row while moving back to the left margin. So in a sense it is not a restriction due to having to view the code on a terminal (or a cmd window or xterm), but it is a readability mandate. I find myself breaking the rule by one or two characters at times, but overall I don't mind it. Also, I hardly ever have to use the \ continuation character, as I take advantage of the implicit continuation in lists.

Marco
  • 1,346
  • 8
  • 9
  • 1
    I find the code looks confusing when line breaks are added at arbitrary places (like 79 characters). The PEP 8 `class Rectangle` example, for instance. I look at the first `if` statement and have to look over each line to find where the actual code block starts. There's three lines of `if` statement and one space added to the code block. Messes with my head. – dave Oct 25 '10 at 07:17
  • 2
    I find it easy to read that rather long if statement. The breaks are not consistent in line length, but they are consistent by always breaking with a conjunction operator. I too struggle with it. Also, with a wide screen monitor you can put two files side by side, and that is definitely a plus. – Marco Oct 25 '10 at 07:22
4

I set my editor to show me the 80-character limit line, and I use it as a warning, not a stop sign. If I can continue the line neatly to the next line before hitting the limit, I do so. However, if putting in a continuation makes it hard to read or makes it confusing, I have a long line. I won't make code harder to read just for the sake of a guide.

JerseyMike
  • 849
  • 7
  • 22
3

No Way.

✔ My Arguments:

  • Anything beyond 80 chars is part of less important logic. (If needed people can scroll right)
  • Enforcing this rule makes those unimportant code come in front of my eyes to clutter
  • One has to scroll vertically for huge distances all the time than horizontal scrolling occasionally
  • Most modern editors have soft-wrap feature that automates this for any choice of length limit (not just 80)
  • Soft-wrap in modern editors is a keystroke-away, it means is one could get best of both the worlds if lines were left as they are.

✔ Linus Torvalds' Arguments:

  • grep or 'find in files' will fail strings are severed at unintended location.

  • Vertical limit(VT100 terminal) is more painful than 80 char horizontal limit

✔ The verdict:

It's like try-
ing to read
a news arti-
cle written
like this.
nehem
  • 12,775
  • 6
  • 58
  • 84
  • 1
    Thanks for the reference. I also share Linus thought: "_80 characters is causing too many idiotic changes_". – jjmontes May 24 '17 at 17:54
2

You can do whatever you want if it is your codebase. If it is someone else's then you have to play by their rules. Google for example has 2 character indents but PEP 8 says to use 4 spaces. I believe their is some quote from Guido about programming with 2 space indents by day and 4 spaces by night.

I like a character limit even with a widescreen monitor because then I can put frames of code side-by-side.

Code style is really all about personal preference. The important part is consistency. So write your python code anyway that makes you happy.

Evan
  • 6,151
  • 1
  • 26
  • 43
1

As long as you don't have to scroll horizontally on your wide monitor (because I have seen that).

eumiro
  • 207,213
  • 34
  • 299
  • 261
0

PEP8 is for humans but your program will run even if you do not follow it.

If you do not share your code and do not plan to do so, do whatever you want.

If you plan to share some part of your code someday, then you should follow PEP8. I mean, probably nobody will care if a few lines are 85 characters. But the code will be hard to read if it consistently is more than 200 characters wide. If you ever read a newspaper the same issue is involved when the text is formatted using columns.

The solution to the line length problem is probably neither arbitrary line break with continuation characters, nor using implicit lines continuation by enclosing some expressions inside parenthesis. It's probably to introduce intermediate variables and functions to have a code that logically breaks at less than 79 chars.

By the way you may want to stick to a still harder limit. I prefer 72 characters because I can allow one or two additional quoting levels inside 80 characters text mails. If not doing so the identiation will break at first quote.

kriss
  • 23,497
  • 17
  • 97
  • 116
0

As with all style guides, it's just that, a guide. It's up to you whether or not you follow it. The main objective is consistency.

That said, I would recommend adopting an ~80 character limit for the following reasons.

  1. It makes complicated code easier to read.
  2. Get in the habit now for when you work on collaborative projects.
  3. It shows professionalism.
Garrett Hyde
  • 5,409
  • 8
  • 49
  • 55
  • 6
    “It shows professionalism.” — could you expand on what you mean by that? I tend to find that people invoke “professionalism” when they want others to do something, but don’t have an actual reason why they should. – Paul D. Waite Oct 25 '10 at 14:03
  • 3
    If you look at movie scripts, they all follow a specific format. So when you come across a script that doesn't follow this format, you assume the writer is an amateur. I view code the same way. When I see code that doesn't follow some rudimentary style guidelines, I automatically assume the coder doesn't have a lot of coding experience. So in this case, I define "professionalism" to mean 1) you know what you're doing, and 2) you understand general coding practices. – Garrett Hyde Oct 25 '10 at 17:59
  • In 2022 it has become more of a personal preference. For you more than 80 char "it makes complicated code easier to read." To me the 80 char limits make my code very hard to read. It irritates me when debugging, and I do not code as fast. As far as collaborative projects, all my co-worker do not use the 80 char limit. I set my character limit to what is the most comfortable and productive to me. I understand that what look professional to me might not be agreed upon by everyone, and vice versa. – Robin Aug 22 '22 at 18:10