4 ms·
One thing that has always bugged me about PEP8 is the advice about trying to keep line length to <80 characters. It seems a little dated. I basically just comp
by arctangent 15y ago
One thing that has always bugged me about PEP8 is the advice about trying to keep line length to <80 characters. It seems a little dated.
I basically just completely ignore this part of the guidance, even though I know that in theory it makes it hard to edit code via a terminal. But this is not something we ever do in practice where I work - code on servers gets there only by being checked out of SVN.
I personally find it incredibly irritating when I see people who've split a function call over a couple of lines just to try and meet this criterion, e.g.:
def __init__(self, first, second, third,
fourth, fifth, sixth):
Note that if you're creating functions with very long signatures you're probably doing something wrong.
About the only time I make any kind of concession to the line length guidance is when I initialise a big dictionary, e.g.:
my_dict = {
ham: eggs,
bar: quux,
# Snip 10 lines of code
rhubarb: custard
}
(There are often better ways to do this too, but sometimes it's necessary for clarity to build a dictionary all at once like this.)
I'm perfectly happy to initialise dictionaries with a small number of keys just like this:
my_dict = { ham: eggs, bar: quux, rhubarb: custard }
- gbog 15y agoSome people like to split windows vertically, shorter line help them, but splitting lines break greppability, and I am always wondering how to indent them properly.
- jlarocco 15y agoThe original reason may be dated, but there are other places where limiting line length is still helpful. For example, I'll often have my editor open and docs open in a web browser right next to it. It also helps when viewing side by side diffs.
- notatoad 15y agoi love the 80char limit. it makes things nice in a terminal, it lets me tile lots of windows across my screen, and it prevents excessively clever but entirely unreadable one-liners.
- sixtofour 15y agoIt's easier to read something quickly if your eyes don't have to travel far. This is why newspapers (remember them?) are written in multiple columns across the page. This may be less of an issue with code, due to its structure, but I still find it much easier to read 80 column code than code that stretches across the screen. If I'm reading code in an 80 column terminal I prefer the line breaks to come from the human that wrote it, to show and reveal structure, rather than having it arbitrarily broken at 80 columns by the editor. Another reason is that most of your code won't stretch across the screen, but you need your window sized for the small amount of code that does, losing a bunch of screen estate to empty space. But I don't worry too much about it.
- levesque 15y agoThis is an interesting bit of information. I sometimes find that an equation is harder to read after breaking it in many parts due to the 80 columns limit. It seems there is a compromise to make between the readability of single statements versus the readability of the code as a whole.
- sixtofour 15y agoPersonal preference can confound any rule of thumb. Cherry picked from here: https://duckduckgo.com/?q=readability+%22column+width%22 https://duckduckgo.com/?q=readability+%22column+width%22 https://en.wikipedia.org/wiki/Column_%28typography%29 https://en.wikipedia.org/wiki/Column_%28typography%29 "For best legibility, typographic manuals suggest that columns should contain roughly 60 characters per line.[1] One formula suggests multiplying the point size of the font by 2 to reach how wide a column should be in picas[2] — in effect a column width of 24 ems. Following these guidelines usually results in multiple narrow columns being favored over a single wide column.[3]" http://psychology.wikia.com/wiki/Readability http://psychology.wikia.com/wiki/Readability "Ease-of-reading is the result of the interaction between the text and the reader. In the reader, those features affecting readability are 1. prior knowledge, 2. reading skill, 3. interest, and 4. motivation. In the text, those features are 1. content, 2. style, 3. design, and 4. structure[1]. The design can include the medium, layout, illustrations, reading and navigation aids, typeface, and color. Correct use of type size, line spacing, column width, text-color-background contrast and white space make text easy to read. "
- Luyt 15y agoThe 80-char limit recommendation is a thing I regularly sin against; most of the time caused by a comment behind a statement.
- calpaterson 15y agoPeople seem disregard this rule as "dated" without actually providing much argument! The reason is that with a larger screen you can get more than one file on the screen at once, and the usability of that massively trumps any minor linebreaking issues.
- clarkevans 15y agoExcept if you're over 40 and have to use a large font. My font is set so that 80 characters is full-width, those who assume 132 characters and wrap mostly around 100 make for incredibly horrible code reading experience. I also print out complex code fragments or read them on a tablet. In this format 80 characters or less is also quite excellent. Finally, to I try limit to 76 characters. It permits you to do "> > " in e-mail conversations about the code without having it auto-wrap in mutt.
- GeneralMaximus 15y agoI dislike the 80 character limit, too. But having no limit at all would be a disaster for readability. I believe a 100 or 120 character limit is a nice compromise.
- Derbasti 15y agoI used to disregard this for the same reasons you are disregarding it. But at some point I realized that (a) I prefer big font sizes (~13 pt regardless of with/without glasses) (b) I like to have two columns of code next to each other. (c) IDEs love to cramp up my work space with vertical side bars. All that conspires to put horizontal space at a premium. I usually go for 80 chars now. Some languages are more verbose than others though. Cocoa at 80 chars just looks wrong, so in that case, I will take 100 chars. Addendum: (d) Vim sucks at horizontal scrolling.