Python coding standards/best practices
Question:
In python do you generally use PEP 8 — Style Guide for Python Code as your coding standards/guidelines? Are there any other formalized standards that you prefer?
Answers:
Yes, I try to follow it as closely as possible.
I don’t follow any other coding standards.
I follow it extremely rigorously. The only god before PEP-8 is existing code bases.
I follow the Python Idioms and Efficiency guidelines, by Rob Knight. I think they are exactly the same as PEP 8, but are more synthetic and based on examples.
If you are using wxPython you might also want to check Style Guide for wxPython code, by Chris Barker, as well.
“In python do you generally use PEP 8 — Style Guide for Python Code as your coding standards/guidelines? Are there any other formalized standards that you prefer?”
As mentioned by you follow PEP 8 for the main text, and PEP 257 for docstring conventions
Along with Python Style Guides, I suggest that you refer the following:
PEP 8 is good, the only thing that i wish it came down harder on was the Tabs-vs-Spaces holy war.
Basically if you are starting a project in python, you need to choose Tabs or Spaces and then shoot all offenders on sight.
To add to bhadra’s list of idiomatic guides:
Checkout Anthony Baxter’s presentation on Effective Python Programming (from OSON 2005).
An excerpt:
# dict's setdefault method turns this:
if key in dictobj:
dictobj[key].append(val)
else:
dictobj[key] = [val]
# into this:
dictobj.setdefault(key,[]).append(val)
I stick to PEP-8 very closely.
There are three specific things that I can’t be bothered to change to PEP-8.
-
Avoid extraneous whitespace immediately inside parentheses, brackets or braces.
Suggested: spam(ham[1], {eggs: 2})
I do this anyway: spam( ham[ 1 ], { eggs: 2 } )
Why? 30+ years of ingrained habit is snuggling ()’s up against function names or (in C) statements keywords. Starting with Fortran IV in the 70’s.
-
Use spaces around arithmetic operators:
Suggested: x = x * 2 - 1
I do this anyway: x= x * 2 - 1
Why? Gries’ The Science of Programming suggested this as a way to emphasize the connection between assignment and the variable who’s state is being changed.
It doesn’t work well for multiple assignment or augmented assignment, for that I use lots of spaces.
-
For function names, method names and instance variable names
Suggested: lowercase, with words separated by underscores as necessary to improve readability.
I do this anyway: camelCase
Why? 20+ years of ingrained habit of camelCase, starting with Pascal in the 80’s.
I follow the PEP8, it is a great piece of coding style.
In python do you generally use PEP 8 — Style Guide for Python Code as your coding standards/guidelines? Are there any other formalized standards that you prefer?
Yes, I try to follow it as closely as possible.
I don’t follow any other coding standards.
I follow it extremely rigorously. The only god before PEP-8 is existing code bases.
I follow the Python Idioms and Efficiency guidelines, by Rob Knight. I think they are exactly the same as PEP 8, but are more synthetic and based on examples.
If you are using wxPython you might also want to check Style Guide for wxPython code, by Chris Barker, as well.
“In python do you generally use PEP 8 — Style Guide for Python Code as your coding standards/guidelines? Are there any other formalized standards that you prefer?”
As mentioned by you follow PEP 8 for the main text, and PEP 257 for docstring conventions
Along with Python Style Guides, I suggest that you refer the following:
PEP 8 is good, the only thing that i wish it came down harder on was the Tabs-vs-Spaces holy war.
Basically if you are starting a project in python, you need to choose Tabs or Spaces and then shoot all offenders on sight.
To add to bhadra’s list of idiomatic guides:
Checkout Anthony Baxter’s presentation on Effective Python Programming (from OSON 2005).
An excerpt:
# dict's setdefault method turns this:
if key in dictobj:
dictobj[key].append(val)
else:
dictobj[key] = [val]
# into this:
dictobj.setdefault(key,[]).append(val)
I stick to PEP-8 very closely.
There are three specific things that I can’t be bothered to change to PEP-8.
-
Avoid extraneous whitespace immediately inside parentheses, brackets or braces.
Suggested:
spam(ham[1], {eggs: 2})I do this anyway:
spam( ham[ 1 ], { eggs: 2 } )Why? 30+ years of ingrained habit is snuggling ()’s up against function names or (in C) statements keywords. Starting with Fortran IV in the 70’s.
-
Use spaces around arithmetic operators:
Suggested:
x = x * 2 - 1I do this anyway:
x= x * 2 - 1Why? Gries’ The Science of Programming suggested this as a way to emphasize the connection between assignment and the variable who’s state is being changed.
It doesn’t work well for multiple assignment or augmented assignment, for that I use lots of spaces.
-
For function names, method names and instance variable names
Suggested: lowercase, with words separated by underscores as necessary to improve readability.
I do this anyway: camelCase
Why? 20+ years of ingrained habit of camelCase, starting with Pascal in the 80’s.
I follow the PEP8, it is a great piece of coding style.