We have to adopt a style for presenting
Python. We won't present a complete set of
, instead we'll present examples. This
section has some justification of the style we use for the examples in
Just to continune this rant, we find that actual examples speak
louder than any of the gratuitously detailed coding standards which are
so popular in IT shops. We find that many
IT organizations waste considerable time trying to
write descriptions of a preferred style. A good example, however, trumps
any description. As consultants, we are often asked to provide standards
to an inexperienced team of programmers. The programmers only look at
the examples (often cutting and pasting them). Why spend money on empty
verbiage that is peripheral to the useful example?
One important note: we specifically reject using complex prefixes
for variable names. Prefixes are little more than visual
clutter. In many places, for example, an integer parameter with
the amount of a bet might be called
the prefix indicates the scope (
for a parameter)
and type (
for an integer). We reject the
pi_ as useless and uninformative.
This style of name is only appropriate for primitive types, and
doesn't address complex data structures well at all. How does one name a
parameter that is a list of dictionaries of class instances?
In some cases, prefixes are used to denote the scope of an
instance variables. Variable names might include a cryptic one-letter
prefix like “f” to denote an instance variable; sometimes
programmers will use “my” or “the” as an
English-like prefix. We prefer to reduce clutter. In Python, instance
variables are always qualified by
self., making the
scope crystal clear.
All of the code samples were tested on Python 2.5 for MacOS, using
an iMac running MacOS 10.5. Additional testing of all code was done with
Windows 2000 on a Dell Latitude laptop, as well as a Dell Precision
running Fedora Core.