Zero Piraeus <sche...@gmail.com> writes:
> :
>
(Why is this colon appearing at the top of your messages? Can you remove
it if it's not germane?)
> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:
> 1. Say "screw it" and go past 79, PEP8 be damned.
There are many people who are irritated by Python code that has lines
longer than 80 characters. In my experience, though, it's much easier to
read code which is written using a strict maximum length of 80
characters per line, and code which tends to exceed that length is
strongly correlated with code which is difficult to read for other
reasons too.
> 2. Say "screw it" and break the line using a backslash.
Never this. A backslash is almost never a good choice (it leaves the
code in a state that an invisible difference – trailing whitespace – can
cause it to break), especially because there are so many other better
options.
> 3. Say "well, at least it's not a backslash" and break the line using
> parentheses.
Long lines frequently have some kind of bracketing syntax (parentheses,
brackets, braces, triple-quotes, etc.) which make it easy to break the
line properly. That's a natural place to break the line, and the
continuations should all be indented 8 characters (recommended in PEP 8
also).
> 4. Spend 45 minutes trying to think up shorter [but still sensible]
> variable names to make it fit.
If the names are so long that they make it difficult to fit the line
within 80 characters, one of the following is probably true:
* The line is indented too far. Re-factor the chunk of code to a smaller
function.
* The line is too complex. Break it into several smaller statements.
* The names are too long. Make them descriptive, but not huge. In a
simple function (which all of them should ideally be) there should be
few enough names involved that they can all be short. Corollary: if
the names are too long, the function is probably too dependent on a
large context.
> 5. Perform an otherwise pointless assignment to a temp variable on the
> previous line to make it fit.
Using assignments for intermediate steps is not pointless. One
significant benefit is that it makes the code more obvious to the
reader.
> 6. Realise that if it's that long, it probably shouldn't have been a
> list comprehension in the first place.
List comprehensions are already within bracketing syntax, so are
trivially easy to break across multiple lines.
> Any I've missed? Any preferences?
I prefer continuation lines to look like this::
def prepare_smorgasbord(
smorgasbord_class, poultry, food_preparation_handbook):
""" Prepare the smorgasbord with poultry.
The `food_preparation_handbook` is used to cite a warning if
a gizzard is past its expiration date.
"""
smorgasbord = smorgasbord_class()
for item in [
foo for foo in
poultry.giblets.iteritems()
if foo.type = 'gizzard']:
smorgasbord.add(
prepare_gizzard_for_consumption(item))
if item.expiry < datetime.datetime.now():
smorgasbord.flag(
food_preparation_handbook.warning("Only for the brave"))
return smorgasbord
Every statement should stay beyond the starting level of indentation;
returning to the same level of indentation or earlier should only happen
when a new statement occurs.
The 8-column indentation makes it clear that this is not a new code
block, making it obvious to the eye where a code block (indented at 4
columns) actually starts.
That's a contrived example, obviously, and for some of those things I'd
probably be tempted to re-factor self-contained parts to separate
functions in order to make the code at this location simpler. But it
illustrates the line continuation style I advocate.
--
\ “Program testing can be a very effective way to show the |
`\ presence of bugs, but is hopelessly inadequate for showing |
_o__) their absence.” —Edsger W. Dijkstra |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
