Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #51491 > unrolled thread

Re: PEP8 79 char max

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: PEP8 79 char max Ed Leafe <ed@leafe.com> - 2013-07-29 15:18 -0500
    Re: PEP8 79 char max Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-29 21:34 +0000
      Re: PEP8 79 char max Joshua Landau <joshua@landau.ws> - 2013-07-29 23:24 +0100

#51491 — Re: PEP8 79 char max

On Jul 29, 2013, at 3:08 PM, Joel Goldstick <joel.goldstick@gmail.com> wrote:

>> Would following
>> this recommendation improve script performance?
> 
> Not performance, but human readability

	IMO, this isn't always the case. There are many lines of code that are broken up to meet the 79 character limit, and as a result become much less readable. 


-- Ed Leafe

[toc] | [next] | [standalone]

#51501

On Mon, 29 Jul 2013 15:18:59 -0500, Ed Leafe wrote:

> On Jul 29, 2013, at 3:08 PM, Joel Goldstick <joel.goldstick@gmail.com>
> wrote:
>> Not performance, but human readability
> 
> 	IMO, this isn't always the case. There are many lines of code 
that are
> 	broken up to meet the 79 character limit, and as a result become 
much
> 	less readable.

Speaking of readability, what's with the indentation of your post? The 
leading tab plays havoc with my newsreader's word-wrapping.

Breaking lines to fit in 79 characters should almost always be perfectly 
readable, if you break it at natural code units rather than at random 
places. E.g. I have a code snippet that looks like this:

[....whatever...]
else:
    completer = completer.Completer(
                    bindings=(r'"\C-xo": overwrite-mode',
                              r'"\C-xd": dump-functions',
                              )
                            )

I'm not entirely happy with the placement of the closing brackets, but by 
breaking the line at the arguments to Completer, and then putting one 
binding per line, I think it is perfectly readable. And much more 
readable than (say) this:


else:
    completer = completer.Completer(bindings=
        (r'"\C-xo": overwrite-mode', r'"\C-xd": dump-functions',))


As far as I can tell, that's pretty much the longest line I have in my 
personal code base, possibly excepting unit tests with long lists of 
data. I simply don't write deeply nested classes and functions unless I 
absolutely need to.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#51513

[Multipart message — attachments visible in raw view] — view raw

On 29 July 2013 22:34, Steven D'Aprano <steve+comp.lang.python@pearwood.info
> wrote:

> On Mon, 29 Jul 2013 15:18:59 -0500, Ed Leafe wrote:
>
> > On Jul 29, 2013, at 3:08 PM, Joel Goldstick <joel.goldstick@gmail.com>
> > wrote:
> >> Not performance, but human readability
> >
> >       IMO, this isn't always the case. There are many lines of code
> that are
> >       broken up to meet the 79 character limit, and as a result become
> much
> >       less readable.
>
> Speaking of readability, what's with the indentation of your post? The
> leading tab plays havoc with my newsreader's word-wrapping.
>
> Breaking lines to fit in 79 characters should almost always be perfectly
> readable, if you break it at natural code units rather than at random
> places. E.g. I have a code snippet that looks like this:
>
> [....whatever...]
> else:
>     completer = completer.Completer(
>                     bindings=(r'"\C-xo": overwrite-mode',
>                               r'"\C-xd": dump-functions',
>                               )
>                             )
>
> I'm not entirely happy with the placement of the closing brackets, but by
> breaking the line at the arguments to Completer, and then putting one
> binding per line, I think it is perfectly readable. And much more
> readable than (say) this:
>
>
> else:
>     completer = completer.Completer(bindings=
>         (r'"\C-xo": overwrite-mode', r'"\C-xd": dump-functions',))
>

But less readable to me than:

    completer = completer.Completer(bindings=[r'"\C-xo": overwrite-mode',
r'"\C-xd": dump-functions'])

Personal preference.

As far as I can tell, that's pretty much the longest line I have in my
> personal code base, possibly excepting unit tests with long lists of
> data. I simply don't write deeply nested classes and functions unless I
> absolutely need to.


I'd go for:

    completer = completer.Completer(bindings=[
  r'"\C-xo": overwrite-mode',
  r'"\C-xd": dump-functions'
    ])

although possibly drop the "bindings=" if possible. "[]" is less ambiguous
a construct than "()"¹ and the "balance" of the code is better my way if
such ephemeral ideas as that count.

Anyway, the point I'm trying to make is that *line length is a personal
thing*. There are two rules:

1) Stick with what other people on the team are doing, if relevant
2) Don't be stupid

The rest is your choice. Some people like 80 character limits, but I've
consistently preferred "whatever you think" as a better rule.

¹ As in there are fewer possible uses, so it's quicker to know what you're
using it for

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web