About the 79 character line recommendation

[Steve Bergman]

As I study Python, I am trying to develop good, Pythonic, habits. For
one thing, I am trying to keep Guido's the style guide in mind.

And I know that it starts out saying that it should not be applied in
an absolute fashion.

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.

So, I was wondering what more accomplished Python programmers thought
about this.

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?

Thanks,
Steve Bergman

[sam]

Steve Bergman wrote:

As I study Python, I am trying to develop good, Pythonic, habits. For
one thing, I am trying to keep Guido's the style guide in mind.

And I know that it starts out saying that it should not be applied in
an absolute fashion.

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.

So, I was wondering what more accomplished Python programmers thought
about this.

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?

Thanks,
Steve Bergman

I prefer to use 132 char per line, and like you I line up the = sign
for readability.
The reason for this convention arises from the fact that I am Dyslexic,
and this convention helps me double check my typing.

Sam Schulenburg

[John Machin]

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

[Virgil Dupras]

Steve Bergman wrote:

As I study Python, I am trying to develop good, Pythonic, habits. For
one thing, I am trying to keep Guido's the style guide in mind.

And I know that it starts out saying that it should not be applied in
an absolute fashion.

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.

So, I was wondering what more accomplished Python programmers thought
about this.

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?

Thanks,
Steve Bergman

I also think that limiting code to 80 columns often hinders
readability. I personally try to limit my code to 100 columns. The end
result is pretty nice.

However, I'm all for the "flat is better than nested" philosophy, even
when nested is under 100 columns.

[Steve Bergman]

Thanks for the responses.

The point about 132 columns is good. Pretty much any printer will
handle that today, though I reserve the right to change my mind about
the utility of 17cpi print after I'm 50. Hopefully, all printers will
be at least 1200dpi by then. ;-)

---

Yes, I dislike "\" for continuation, and use the implicit continuation
between parentheses, braces, etc. wherever possible. I don't mind
breaking up comma separated values like function method arguments, but
I very much dislike breaking at an "=" sign.

(BigLong VariableName
= BigLongMethodCallWithALotOfArguments)

Come to think of it, though, I'm working mostly in TurboGears (web
devel framework) which may not represent python code in general all
that well wrt line length. Lot's of lines that are harder to break up
than in some other environments, perhaps.

---

I'm finding 100 to be a nice balance. It forces me not to be lazy and
allow really long lines, but allows me to format so as to make the
meaning most clear.

[Marc 'BlackJack' Rintsch]

In <11*********************@n67g2000cwd.googlegroups. com>, Steve Bergman
wrote:

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?

That may help readability a little bit but if one of the lines will be
changed the other lines have to be changed too which results in a diff
that masks the "real" change a bit. If just one line changes it's easier
to read and follow diffs from version control systems.

Ciao,
Marc 'BlackJack' Rintsch

[sjdevnull]

Olivier Langlois wrote:

There was a coding standard where I worked and the intention behind this
requirement was to make the code printer friendly. Printing code source
with lines longer than 80 chars greatly hinder readability on paper.

I don't think I've ever seen Python code printed out other than in
books. Indeed, I don't think I've seen anyone print their code in any
language in a decade--it's much easier to read online with tags, class
browsers, easy access to version history, etc.

The 79-column limit is a hard rule most places I've worked, because
pretty much all code is going to wind up with someone looking at it on
an 80-column terminal at some point.

[Michele Simionato]

Steve Bergman wrote:

>
So, I was wondering what more accomplished Python programmers thought
about this.

I *hate* people using more than 79 chars per line! ;) They look
horrible in emacs
and horrible on print. I never found the need for longer lines. The
limit also acts
as a deterrent against extra-large one-liners.

Finally, notice that you can alwasys aliases if you are a lazy typist:

shortcut = LongClassName.LongAttributeName

This also saves an attribute access and gives you some additional
speed, which may
be useful in some cases.

Michele Simionato

[Ramon Diaz-Uriarte]

On 5 Dec 2006 13:28:22 -0800, Steve Bergman <st***@rueb.comwrote:

(...)

>
I'm finding 100 to be a nice balance. It forces me not to be lazy and
allow really long lines, but allows me to format so as to make the
meaning most clear.

But if you use some advanced editors (such as Emacs) that easily allow
you to see/edit the same file in two buffers side by side, then going
beyond 80 chars is often a bad idea, specially if you use a laptop.
(And, of course, there is the eternal issue of doing a simple "a2ps"
to print some code; longer than 80 and you often have hard to read
pages).

Best,

R.

--
Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz