Content-Type: RST Love it or hate it, "PEP8_" is something every Python developer has heard of at least once. And, even if you haven't before, if you look at my code, you'll always notice that I very seldom have lines exceeding 80 characters in length, have certain spacing, my methods are always capitalizedLikeThis(), my ClassesLikeThis, and my variables_like_this. These are all specifications of PEP8, either loosely or strictly followed by me in order to ensure other Python programmers don't tear their hair out while reading my code. Before I dig into PEP8, though, let's look at PEP20: .. _PEP8 : http://www.python.org/dev/peps/pep-0008/ .. sourcecode :: plaintext >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! .. figure :: http://blog.opensourcenerd.com/upload/salute For those about to code, we salute you! So, PEP8: what is it? A PEP is a "Python Enhancement Proposal", a statement by the PSF_ about either a feature that should be implemented, advice/rules for coders to keep in mind, etc. PEP8 focuses on being a "Style Guide for Python Code". .. _PSF: http://www.python.org/psf/ `I can write my code however I want!` Sure, but I can treat your code however I want, too. Python is an open source language, and while coding closed libraries and programs with it is possible, PEP8 is more oriented at those of us coders who like to share our work to further the society's knowledge. This sentence, being in the state of using proper English words, upon further examination not many sense is found, its horrible style and grammar being the reason. Similarly, code can be a pain to read: .. sourcecode :: python if width == 0 and height == 0 and color == 'red' and emphasis == 'strong' or (highlight > 100 and user in ['superman', 'guido', 'fsufitch']): if x == 4 : print x , y ; x , y = y , x x = x + 1 # Increment x l = 1; I = 1 ... To name just a few from the PEP. With this in mind, let's take a look at some of these "rules": 80 Character Limit ------------------ Ahh, the biggest of them: why limit your beautiful code to only 80 characters per line? Okay, I know that the programmer world is predominantly male, and hence "longer is better", but come on, too long and you get wrapping, which is ugly and hurts. .. figure :: http://blog.opensourcenerd.com/upload/short-cat Short cat is short. Thank you, ED. Seriously, though, in a language where indentation is key to its structure, wouldn't it be a bad idea to randomly have a full unindented line? And while some editors (such as emacs) are nice enough to put a line break notification to signify that a line is wrapping, others don't, which might cause an unwary programmer to indent the wrapped line... leading to ugly results. Plus, compare the following two lines of code in readability: .. sourcecode :: python if width == 0 and height == 0 and color == 'red' and emphasis == 'strong' or (highlight > 100 and user in ['superman', 'guido', 'fsufitch']): if (width == 0 and height == 0 and color == 'red' and emphasis = 'strong' or ( highlight > 100 and user in ['superman', 'guido', 'fsufitch'] )): I would much rather run into the latter in someone else's code, personally. When it's inevitable, because of a long, unbreakable, string, this is an okay rule to break, but otherwise, short is good. Plus, consider all those poor folks using vim_ in a tty console. They're limited to 80 characters! .. _vim: http://www.vim.org Yes, I'm a freak and follow PEP8 in other languages, including HTML. What of it? 4 Space Indentation ------------------- As long as we're on the topic of spacing and how far to the right your code should go, I should mention: indentation is important to Python, so you better do your indentation right. It is four, 4, cuatro, quatre, bin(100) spaces. Two? Too little, can lead to confusion of code blocks on quick reading. Eight? Too many, I don't even know why people in ye olde days of Python used eight. Any other number? You're weird. Naming Conventions ------------------ PEP8 states the following "rules": - Classes should always have upper case initials: `BrowseView` - Constants should always be fully upper case, with underscore spaces: `MAX_ALLOWANCE` - Packages and modules (directories and files) should always be in all lowercase: `/libxml/parsers/minidom.py` - Variables and functions should be all lowercase with underscores: `my_variable.perform_action()` The latter is where I break my commitment to PEP8 by using mixed case in function names: `my_variable.performAction()`. In my previous life, I wrote Pascal and Java code, and just as I'm having trouble adjusting from "this type of strings" to 'this type', I'd rather keep my variables and functions looking different. Comments -------- I really shouldn't discuss this now, as it's part of a different talk on documentation... However, comments should never subtract from readability. Multiline comments (''' or """) should almost never be used except as docstrings, and single line comments should be hardly necessary if your code is readable (as it should be!) To wrap up, keep this in mind. A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important. But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask! Blind adherence to something right is as stupid as blindly making mistakes. And blinding people with bad code.