[omaha] Fwd: [odynug] Perl Best Practices but for Python

[Matthew Nuzum]

On Fri, Aug 19, 2011 at 9:30 AM, Jeff Hinrichs <jeffh at delasco.com> wrote:

> Agreed pep8 is where to start, then goog for "idiomatic python"
> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html
> That has been presented at a previous omahapython meeting.    Before
> anything else, fire up a python interpreter and then
> >>> import this
>
> read it to get in the mindset of why, then start going through the
> idiomatic
> tutorial.
>
>
Boo. -1 for the RTFM replies. Nothing personal (reading PEP-8 is key) but
there's so much more advice that can be given.

I don't know a book about this but I do work with some awesome Python
developers and I can tell you some of the practices we use for maintainable
code:

Automated tests for everything (with exception, see #1 below). Often TDD but
as long as we have tests it doesn't matter too much what order you did them
in.

Break your code into reusable modules as often as you can.

Follow the spirit of PEP-8 rather than the letter of the law.

Merge proposals. No code goes to production (or even merged to trunk)
without a second set of eyes on it. We use the BZR versioning tool which is
pretty similar to Git for this discussion. You have a trunk branch. When you
want to make a change, you branch from trunk, write your change then propose
your change for merging. After it's been reviewed and approved (which may
mean code changes and re-reviewing) it's merged and goes to production at
the appointed time.

Detailed commit logs. This makes looking at old code so much more pleasant.
I recently had to revisit some code a year and a half old whose original
author left the company. Being able to rewind history and see the commits
made it quite easy to get up to speed.

Don't import * (Michael Foord, a notable python dev who is on our team has
even created modules that redefine True and False with inverted logic to
penalize people who do this with his code)

We do run pep8, a command line tool, on our code frequently. Some use pylint
as well. I think there's another command line tool that is starting to
replace pylint but I don't know what it is off hand.

I'm sure there are other tips people on this list can give more tips.

[1] When don't we write automated tests? When the tests serves no purpose
other than to exercise a framework that has its own tests. For example, a
simple model in Django would not need tests. If it has a custom save
functionality or model methods then it would.

-- 
Matthew Nuzum
newz2000 on freenode, skype, linkedin and twitter

♫ You're never fully dressed without a smile! ♫