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

Groups > comp.lang.python > #51559 > 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 Skip Montanaro <skip@pobox.com> - 2013-07-30 09:06 -0500
    Re: PEP8 79 char max Neil Cerutti <neilc@norwich.edu> - 2013-07-30 14:49 +0000
      Re: PEP8 79 char max Skip Montanaro <skip@pobox.com> - 2013-07-30 10:44 -0500
      Re: PEP8 79 char max Joshua Landau <joshua@landau.ws> - 2013-07-30 17:41 +0100

#51559 — Re: PEP8 79 char max

> In that gauge I would exclude indentation (you don't count the
> number of characters the margin takes) ....

I don't think anyone reads the margins. :-)

That said, I agree that code and prose are fundamentally different
beasts.  Still, when reading either and you get to the end of the
line, you need to shift your gaze down a line and back to the left
margin (or the left margin plus any indentation).  That task becomes
more difficult as line length increases.

As programmers/software engineers, we need to read and write both code
and text. I think 80 columns is still a decent compromise.

Skip

[toc] | [next] | [standalone]

#51566

On 2013-07-30, Skip Montanaro <skip@pobox.com> wrote:
>> In that gauge I would exclude indentation (you don't count the
>> number of characters the margin takes) ....
>
> I don't think anyone reads the margins. :-)
>
> That said, I agree that code and prose are fundamentally
> different beasts.  Still, when reading either and you get to
> the end of the line, you need to shift your gaze down a line
> and back to the left margin (or the left margin plus any
> indentation).  That task becomes more difficult as line length
> increases.

Most research about speed of comprehension of different line
lengths was based on subjects reading prose. The effect of code
line length hasn't been studied extensively.

> As programmers/software engineers, we need to read and write
> both code and text. I think 80 columns is still a decent
> compromise.

So rules of thumb, standardizations, and personal preferences are
mostly what we have to go by.

When code that looks very similar to code you've seen before
really *is* similar to code you've seen before, comprehension
speed can increase. A study of chess masters' ability to memorize
chess positions showed that they were powerfully accurate when
shown positions from real games, but no better than the average
schmoe when shown randomly positioned pieces. So if everyone
basically follows PEP8 we all benefit from playing by the same
game rules, as it were.

-- 
Neil Cerutti

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

#51570

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

> So if everyone basically follows PEP8 we all benefit from playing by
> the same game rules, as it were.

(I think I'm agreeing with you, but nonetheless, I will forge ahead.)

To the extent that 80-column window widths have been common for so
long, PEP 8 or not (and Python or not), there is a ton of code out
there which abides by that convention.  More-or-less unilaterally
increasing the recommended max line width to 100 (or 99?) columns
isn't likely to improve things.  People like me (who prefer the status
quo) will complain about all the new-fangled code written to a wider
standard (and will be tempted to reformat).  People who like the new
standard will complain about old code wasting all that white space
(and will be tempted to reformat). :-)

Finally (I promise this is my last word on the topic), most lines
don't need to be wrapped as they stand today.  See the attached graph
for the distribution of line lengths for the current project where I
spend most of my time these days (just Python code, blank lines
elided, comment lines included).  Stretching the max out to 100
columns when most lines are less than 60 columns just wastes screen
real estate.

Skip

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

#51582

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

On 30 July 2013 16:44, Skip Montanaro <skip@pobox.com> wrote:

> > So if everyone basically follows PEP8 we all benefit from playing by
> > the same game rules, as it were.
>
> (I think I'm agreeing with you, but nonetheless, I will forge ahead.)
>
> To the extent that 80-column window widths have been common for so
> long, PEP 8 or not (and Python or not), there is a ton of code out
> there which abides by that convention.  More-or-less unilaterally
> increasing the recommended max line width to 100 (or 99?) columns
> isn't likely to improve things.  People like me (who prefer the status
> quo) will complain about all the new-fangled code written to a wider
> standard (and will be tempted to reformat).  People who like the new
> standard will complain about old code wasting all that white space
> (and will be tempted to reformat). :-)
>
> Finally (I promise this is my last word on the topic), most lines
> don't need to be wrapped as they stand today.  See the attached graph
> for the distribution of line lengths for the current project where I
> spend most of my time these days (just Python code, blank lines
> elided, comment lines included).  Stretching the max out to 100
> columns when most lines are less than 60 columns just wastes screen
> real estate.
>

Your graph doesn't convince me.

Take this line from earlier, which is currently 102 characters and nearing
my personal limit.

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

Under rules to wrap to 80 characters (and in this case I'd probably do it
anyway), I'd normally wrap to this:

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

of line lengths 46, 36, 35 and 6 respectively. Thus it's impossible to so
easily tell how many lines would be "unwrapped" from your graph.

[toc] | [prev] | [standalone]

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

csiph-web