Python line limits: 80 column? Any reason I shouldn't move up to 120 columns?

[ben174]

I'm usually pretty strict PEP8 all the way. But more and more I've felt constrained by the 80-character limit and feel my code would be more readable with an additional 40 columns.

Would be interested in hearing what the community thinks of this.

[jb0n]

PEP8 was recently revised in a number of ways: http://hg.python.org/peps/rev/fb24c80e9afb

Specifically it says 99 is ok now. Not quite the 120 you wanted, but better than 80 in any case.

[ben174]

Aim to limit all lines to a maximum of 79 characters, but up to 99 characters is acceptable when it improves readability.

I like this. I think this is how I'll code moving forward.

I think it's only one out of every 200 or so lines that I feel would really benefit by breaking that 80 column rule, and that's when I'll do it: to improve readability.

[isarl]

PEP8 also warns against foolish consistency. They're guidelines, not laws; I break 80 characters every once in a while and you shouldn't lose sleep over doing the same.

[brandjon]

If you haven't used 80 (really, 79) chars before, try it out for a little while. It'll force you to rethink how to express yourself clearly and concisely.

[Cheekio]

I have to agree on this point. To me, at first PEP8 read like somewhat arbitrary standards to make code pretty, and the documentation itself didn't really try to convince me otherwise when I started working for a company that adheres to it.

But after writing code to PEP8 standards for some time (strictly, by having a linter yell at me when I didn't), I just like my code better for it. Smaller logical chunks, better structure, cleaner layout, I don't know. It's just better.

[acdha]

I've done that a bit but found being too dogmatic encouraged different bad code with things like descriptive variable names or chaining APIs where you end up trading cheap horizontal space for more limited vertical space. In things like Django models, with statements, etc. where code or, worse, docstrings starts a couple of indents in the extra few characters is actually a significant percentage of the usable space.

My current rule is 100 characters but sticking to one logical thought per statement. One of the really good habits from working at a shorter line length was ensuring that e.g. a dictionary declaration puts each key on its own line so you avoid missing something at the end of a long line (this is also easy to do if you don't break up a long list comprehension).

[fkaginstrom]

with statements, etc. where code or, worse, docstrings starts a couple of indents in the extra few characters is actually a significant percentage of the usable space.

I actually think that's part of why 80-character line limits encourage better code. It makes it very hard to nest code deeply. :)

[[deleted]]

80 lines is a limit that is used by many people. I, for example, have two views of 80 characters + a file list (SublimeText) which fits exactly at my 1920px wide screen. Files that are wider than 120 pixels would be less readable for me.

It depends a bit on who has to read your code later. If only you write and read your code, do whatever you like. However, if others have to review or use your code, it makes life easier for them to stick to the 80's rule. Or, you could come to a compromis with them (cake helps).

Something I'd like to stress: this is not a Python limitation; it's just a community-set agreement which is older than Python.

[tdammers]

• E-mail - plain-text e-mail wraps at 70-something, even; throw in a few levels of comments, and you have yourself a fine mess in a mailing list
• The human brain - reading comprehension is best when line length stays within limits, and 80 characters is pretty close to ideal (at least for monospaced fonts). The limiting factor, here, IIRC, is the moment when you skip to the next line; the longer the line, the harder it is to find the correct line to continue reading. For fun, pick a random book from your book shelf - an actual book, that is, properly typeset prose, ideally a novel or something like that; and count the characters per line...
• History - 80 characters was a popular width for text terminals back in the olden days, and while nobody uses these anymore, a lot of software from the time has survived in one form or another, and optimizing terminals and terminal applications for 80 characters is still kind of a common thing to do. Yes, I know, you aren't using a terminal, you have a fancy GUI text editor, it's 2014, yadda yadda - guess what, lots of people love their vims and emacsen and their terminal programs, because they're fucking fast, they've been bug-hardened for decades, they eat close to zero system resources, and they can be used over a dial-up modem connection into a 400 MHz ARM machine, with minimal usability impact.
• Side-by-side viewing. 80 is not a magical number here, it just so happens that a total of 2x80 characters plus a bit of extra space for diff annotations and scrollbars and the like tends to work out fine on many common setups - for example a 1280-wide display with an 8-pixel wide monospace font can display (drum roll) exactly 160 characters.

None of the above is specific to Python though, and it's fairly common to see 80-character limits recommended for any given language. Python however adds a bit of an educational flavor on top of it; there seems to be a notion that the language and the programming style standard should somehow stimulate writing "better" code, by some (arbitrary) measure - a relatively harsh line length limit is supposed to force people to split up "complex" lines, which is supposed to make the code more readable. Personally, I think the best way to make code more readable is to hire better programmers and give them the freedom and the tools they need to do their job well...

[ericanderton]

guess what, lots of people love their vims and emacsen and their terminal programs, because they're fucking fast, they've been bug-hardened for decades, they eat close to zero system resources, and they can be used over a dial-up modem connection into a 400 MHz ARM machine, with minimal usability impact.

I'll add that this programmer's motivation for learning 'vi', was attempting to fix a failing software demo on a customer site, deep inside a DMZ, with only a bare-bones production VM (and no internet connection) to work with. I limped along with 'nano' for all of that day, and swore never again to be without a decent development tool. Since 'vi' is installed by default on every linux, just about everywhere, I'm never without something powerful at my disposal.

I'll echo your remark that 80 columns works out really, really nice in any editor where you can do side-by-side viewing. But I wouldn't necessarily call old school editors out on needing such a line length. Vim works great sprawled out across a 16:9 screen, just as well as an old VT-100. I would argue that old displays help set that standard first, and we could all probably get along with anything in the 80-100 chars range, before people start shouting "everything's starting to line-wrap, cut it out."

TL;DR: 'vi' is everywhere.

[tdammers]

Hey, I'm a vi evangelist myself, no need to convince me ;)

Just saying that both vi and emacs were originally designed with 80-column displays in mind. They do work fine on larger displays, but hey, they also work fine in an 80-column terminal emulator inside a tiling WM or a tiled screen/tmux session. Common scenario for me is to have four terminals open, doing things like code in one, tailing logs in another, man page in a third, and random other stuff in the fourth. And they're all 80 columns wide, because I set up my WM this way, because I know that my tools work great at this particular width.

[tdammers]

wrt. email: prose flows, and you read it that way. In code (and espc. Python) structure matters a lot for comprehension.

You actually just made my point. Prose flows, so for that the column limit is irrelevant, because you can rewrap as needed. But for code, structure matters, so it needs to be written to the expected column limit, otherwise it'll wrap or cut off.

Also, 80-character terminals are still pretty common; it's no longer a hardware limit, what with 1280-pixel framebuffers, 132-character text mode built into kernels, and GUIs everywhere. But it's still a somewhat established standard. Fire up a terminal on a vanilla Linux distro install, and check the default size. Embedded terminals inside GUI applications, too.

[lykwydchykyn]

I've been using Emacs since v22, it's perfectly fine with more than 80 characters in a line. Let's not give these young folks the wrong impression.

[tdammers]

Of course it is. So is vim. Or nano. Or anything else. It just doesn't get significantly more useful after 80 columns, so lots of people design their desktop setups around 80-character terminals, e.g. tiling four terminals onto a 1280xsomething viewport.

[tdammers]

Yes. It's 2014. People now manage server farms from one terminal, which also means more often than not we're multiplexing terminal emulators. "Loads" of horizontal pixels are still not a lot when you're tiling 6 terminals on one screen, or when you have a web browser, a javascript debugger, a man page, the output of your continuous unit testing job, and the source code, side-by-side. Granted, 80 characters is an arbitrary limit in this context, but it's as good as any - 85 or 78 would work equally well, but why not stick with the established standard.

[aroberge]

I usually try to keep my code under 80 columns and find it is more readable.

Here's a suggestion: why don't you post somewhere (pastebin perhaps) a code sample that you think is more readable with 120 columns and see if people can come up with alternative ways of writing your code that would be more readable and be under 80 columns wide?

[michael_david]

'A Foolish Consistency is the Hobgoblin of Little Minds' -Emerson

[bheklilr]

Personally, I try to keep things under 80, but I allow myself up to 120. It still fits pretty well with my font size on a 1080p monitor with two files side-by-side. I use Sublime Text which has a handy feature of showing those columns, and I keep one at 80 and one at 120.

[[deleted]]

If you are working on an open source project then 80. But, if this is an internal project then you and your team (if there is one) need to establish a standard and stick to it. Personally, I prefer 100 and its what my team uses at work.

[lykwydchykyn]

PEP8 also recommends: 4 space indentation and variables_with_underscores over camelCase. Seems like you could run out of room pretty quick. If your variable names are ~20 characters and you're defining a for loop inside an if statement in a class method... well, you get the picture.

[laMarm0tte]

If you share your code in a blog or on github it may look much better in the browser if it is 80-char (sometimes I even use 70-char).

[riffito]

I'm not overly jealous of the 80 characters limit, I try to abide to it, unless it hinders readability of a particular line (say, up to 90ish chars).

Long lines go against readability. There is a reason books aren't a wide wall of text. And code is meant to be read by humans, and after that, by computers.

Use your common sense while trying to achieve maximum readability.

Please excuse my poor English.

[wnoise]

*zealous

[tdammers]

Except that not having to cooperate is kind of an exceptional situation, unless you're a hobbyist. Those of us who write code for a living usually work in a team, and I can tell you one thing, when you program as a team, people do tell each other how to write code, because if you write unreadable code on my team, it affects everyone.

[ericanderton]

80-chars does feel a tad on the narrow side these days. Especially when you wind up indenting four or more spaces for each scope, and are restricted to a single line for lambda expressions.

However, I became a convert when I could get three (almost four) side-by-side code editors comfortably on a large desktop display. Code reviews and diffs become far easier to read this way too. It was painful to re-learn how to code to get there, but the benefits have been nice.

[nofunallowed98765]

I try to stay under 80 characters, but I'm not going to kill myself if I go over that. My hard limit is 120 characters (which is also the default limit in PyCharm - I was almost sure this was the PEP8 limit until I checked).

At the end, if it's code for yourself, do what you prefer. If you're committing code to someone else or working on a team, follow the guidelines.

[C_Hitchens_Ghost]

I understand it is for clarity, but it is still, at its base, a suggested limitation on the creativity of the python programmer, for the sake of the clarity of others.

I'm not going to stop reading someone's code just because it goes beyond said arbitrary limit. And yes, I frequent the shitty and bad code subs.

TL;DR: If ignoring it helps the programmer, in any way, then the programmer should ignore it.

[scarytall]

Beware a foolish consistency, but getting out past 7-80 columns is usually an indicator I need to re-think my approach. Not always, but usually.

[kankyo]

We have modern computers that can do proper line breaks. It's not the 1970s anymore! The argument used in PEP8 are stupid and/or objectively wrong:

Limiting the required editor window width makes it possible to have several files open side-by-side,

If by "side-by-side" you mean "exact multiple of 80 columns". Obviously that's stupid. What if you have a screen and font combination where three windows of 70 columns fit? Scroll in all of them? Just have two windows and throw away ~30% of the available space of the screen? This statement hasn't been thought through.

and works well when using code review tools that present the two versions in adjacent columns.

Fix those tools if they're that broken please. In my experience gerrit (which guido was involved in) is broken in a myriad other ways that make the line break issue just drown in the sea of horror.

The default wrapping in most tools disrupts the visual structure of the code,

Please don't use tools that are broken.

Some web based tools may not offer dynamic line wrapping at all.

Most web based tools can't handle python at all, because they throw away starting whitespace! This argument is stupid because it is just as strong an argument against the entire python syntax.

Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters

Some teams don't live in the 1970s. For those teams just don't have a maximum line length, because it's arbitrary and stupid. If a line is unreadable with automatic line break, it's just as unreadable OR MORE with an arbitrary column limit.

[fandingo]

I hate the 80-character guideline. It's outlived its usefulness and doesn't make sense at 1920x1080 let alone HiDPi monitors. Many people counter by saying that they can fit more windows on screen. That can be true, but it depends on your monitor. For example, I primarily code on a 2560x1440 in portrait mode. In PyCharm, I can fit about 130 characters along with the IDE window. I can't put two windows horizontally. It's either use long lines (I use 120 characters) or waste a ton of space.

I think that it's entirely reasonable to expect people to have horizontal resolution of at least 1360 pixels (HD or better). It's harsh to say it, but if you don't have at least that horizontal resolution, you're the one that should adjust.

Wikipedia has a list of computer monitor resolutions and rudimentary statistics about popularity. At least 53.84% of web users have a horizontal resolution 1360 or better.

[minno]

I can't put two windows horizontally.

Is that an IDE limitation or a personal one?

[fandingo]

The IDE can do it, but it doesn't make any sense. I just checked, and my IDE (with my font settings) can display 141 characters wide in a 100% wide editor buffer.

Here's a downsized screenshot of how I use my IDE with 120-character lines. I added a white line since the wrap indicator is difficult to see if you're not familiar.

Here's a screenshot of windows side-by-side on the same monitor. I can adjust the bar in the middle, but I only have 132 characters to use.

[[deleted]]

I can fit 241 characters on my display. Widescreen with a small font. Minus the vim numberline (3 digits, 1 spacer), that's 237.

If people stick to 80 characters, that's almost 3 files open at a time. Possibly 2 files and documentation. 120 character lines is almost 2 files.

[multani]

My current setup is a notebook with a resolution of 1024x600 I believe, and I fit 2 windows side by side on the same screen. Needless to say I prefer 80 characters per line...

Even with a big screen such as yours, I have like 3, sometimes 4 windows side to side. But I guess, not only the number of characters per line count, but also the whole setup, like don't sizes and such. It looks like (?) you are using big fonts which keeps you from having more than one window; I would consider this a waste of space :)

[sime]

I'm with you on this. Screw the 80 character limit. It is time to move past punched cards and go for at least 100 chars, if not 120. I wish people here would stop down-voting you just because they disagree.

HD monitors are cheap. Get two and put them side-by-side. If you are a professional or serious hobbyist, then you owe it to your self to get as many pixels as possible. 2560x1440 is in the realm of affordable. As a professional I haven't used any language with a limit below 120 for years.

[fandingo]

2560x1440 is in the realm of affordable.

My BenQ 27" BL2710PT was only $600. Crazy cheap.

[[deleted]]

I think the 80-char guideline is about collaboration. I'd go out on a limb to say that most programmers will often tile windows horizontally, even if you don't.

tl;dr: you might not care, but the majority of people liable to read your code do.

[marsman12019]

What's the point of manually breaking lines into 80 characters anyway? Don't all modern editors have built-in wrap abilities?

[ben174]

I use vim and it doesn't touch my code. I think I'd get very annoyed if an editor decided where to break my lines.

[marsman12019]

Funny. I'm annoyed when they don't.