Steve Bergman wrote:
[snip]
> However, I am finding that the 79 character line prescription is not
> optimal for readability.
>
> Certainly, cutting back from the length of lines that I used to use has
> *helped* readability. But if I triy very hard to apply 79, I think
> readability suffers. If this were just something that was an issue
> occasionally, I would just put it off to "know when to break the
> rules". However, find myself going to 90 to 100 characters very
> frequently. Now, if it were just me, I'd shoot for < 100. However,
> the Python philosophy includes making code easier for others to read,
> as well.
>
Are you taking advantage of all the various options for line
continuation besides \ that exist in Python, like (a) automatic
concatenation of adjacent string literals (b) automatic continuation
until () [] or {} are balanced? Example using both:
fprintf(self.logfile,
"WARNING *** Conflict between "
"std format code %d and its format string %r\n",
fmtcode, unistrg)
Aside: In this most noble of languages, fprintf() has a one-line
implementation:
def fprintf(f, fmt, *args):
f.write(fmt % args)
>
> While I'm on this general topic, the guide mentions a pet peeve about
> inserting more than one space to line up the "=" in assignment
> statements. To me, lining them up, even if it requires quite a few
> extra spaces, helps readability quite a bit. Comments?
Merely aligning the = would annoy the crap out of me. However if the
RHS of a bunch of *related* assignments could be made clearer by
inserting extra space, *and* they were more complicated than the
following trivial example of what I mean, I'd do it.
red = c & 0xff
green = (c >> 8) & 0xff
blue = (c >> 16) & 0xff
c.f.
red = c & 0xff
green = (c >> 8) & 0xff
blue = (c >> 16) & 0xff
Cheers,
John
--
http://mail.python.org/mailman/listinfo/python-list
