PEP 8 : Maximum line Length :

[Ganesh Pal]

Hi Team ,


what would be the best way to intent the below line .

I have few lines in my program exceeding the allowed maximum line Length of
79./80 characters

Example 1 :

p =
Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)


Iam running pylint and it says the above line is tool long how do I limit
it to 79 character without violating any rules

************* Module isi_corrupt
C: 14,0: Line too long (88/80)
W: 19,0: Bad indentation. Found 6 spaces, expected 8


Regards,
Ganesh

 

[Rustom Mody]

Hi Team ,


what would be the best way to intent the below line .

I have few lines in my program exceeding the allowed maximum line Length of 79./80 characters


Example 1 :


p = Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)

First rule of python-list: Pay careful attention to Peter Otten.

That said...

80-character limit?!

Sheesh! A relic of the days when terminals were ASCII and 80x24

I wrote about this
http://blog.languager.org/2012/10/layout-imperative-in-functional.html

While its mostly haskell oriented, the comments are amusingly related to this
question in any language:

Comment:
It is kind of ironic that the blog format wraps your wide code examples at 65
chars.

What this goes to show is that while 80 is ridiculously low by most displays today,
it is too high for many web/mailing-list fora.

Of course a standard helps in removing superfluous variations.

Still... its 2014 and 80-columns is as current and relevant as ASCII.

PS.

Last rule of python list: Always listen to Peter Otten.

 

[Roy Smith]

Hi Team ,


what would be the best way to intent the below line .

I have few lines in my program exceeding the allowed maximum line Length of
79./80 characters

Example 1 :

p = Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)

The problem here is not so much that you've exceeded 80 columns, but that there's no logical
structure which gives your eyes (and your brain) hints about how to parse this. I would
start by adding some white space

p = Subprocess.Popen(shlex.split(cmd), stdout=subprocess.PIPE, stderr=subprocess.PIPE)

now, at least, it's easier to see where each argument stops and the next one starts. But,
I would really break this up into multiple lines

 

[Tim Chase]

Changing the name on the first line doesn't entail changing any
other line::

proc = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

special_process_map[this_process] = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

I second the idea of just putting each-of-many-parameters on its own
line. Not only that, I also like to tack on trailing commas and put
the closing paren on its own line to make diffs easier to read:

special_process_map[this_process] = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
)

so that when I add the inevitable parameter, the diff merely reads
like

--- tim1.txt 2014-05-13 07:44:42.441754319 -0500
+++ tim2.txt 2014-05-13 07:45:35.753755858 -0500
@@ -2,4 +2,5 @@
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
+ bufsize=1024,
)

which is quite clear that just one line was added, compared to

--- ben1.txt 2014-05-13 07:44:51.033754566 -0500
+++ ben2.txt 2014-05-13 07:45:46.737756176 -0500
@@ -1,4 +1,5 @@
special_process_map[this_process] = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
- stderr=subprocess.PIPE)
+ stderr=subprocess.PIPE,
+ bufsize=1024)

which makes me have to think/verify about whether anything else
changed between insertion and deletion of lines.

-tkc

 

[Steven D'Aprano]

What this goes to show is that while 80 is ridiculously low by most
displays today,

Not for people who like to has two (or three, or four) windows side-by-
side. Or multiple views of the same document.

it is too high for many web/mailing-list fora.

And smart phones.


[...]

PS.
Last rule of python list: Always listen to Peter Otten.

Yes. Peter is a treasure to the community, not just for his knowledge but
for his patience and friendliness.

 

[Gregory Ewing]

The 80 character line limit is *not* driven by a limitation of computer
technology; it is driven by a limitation of human cognition. For that
reason, it remains relevant until human cognition in the general reading
population improves.

Another thing: Just because I may have 2048 pixes of
horizontal space available on my monitor, that doesn't
mean I want to devote all of them to displaying a
single source file.

I like to be able to put 2 or 3 source windows side
by side, or have a web browser showing documentation
alongside while I work, etc.

While the limit doesn't have to be exactly 80 chars,
something not too much bigger is a good idea for a
variety of reasons.

 

[Roy Smith]

That is PEP 8 conformant, but I find it hurts maintainability: it is far
too much indentation. Horizontal space is costly, because so much
indentation severely limits the length of names etc. that you can use on
the continuation lines.

It only does that if you limit yourself to 80 character lines.

 

[Terry Reedy]

There's also the fact that, while the capacity of monitors to display
pixels has dramatically increased in recent decades, the capacity of
human cognition to scan long lines of text has not increased at all in
that time.

The 80 character line limit is *not* driven by a limitation of computer
technology; it is driven by a limitation of human cognition. For that
reason, it remains relevant until human cognition in the general reading
population improves.

I use the monitor capacity to have 2 or even 3 code windows open
side-by-side. Really handy.

 

[Albert van der Horst]

Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)


First rule of python-list: Pay careful attention to Peter Otten.

That said...

80-character limit?!

Sheesh! A relic of the days when terminals were ASCII and 80x24

80 character was the hard limit.
The soft limit for readability is 60..65 characters.
Think about it.

Just that a language accepts
#define MASK_SEPIA_INTERNAL_BLEEDING_WASHINGTON_DC_BLACK 0x147800fa
means that it is a good idea to do so.

Groetjes Albert

 

[Gary Herron]

Which is a relic of the even older punch cards which contained one line
of (up to) 80 characters.

Gary Herron

 

[Mark Lawrence]

Which is a relic of the even older punch cards which contained one line
of (up to) 80 characters.

Gary Herron

I still remember the cry of anguish when the guy in the computer
building at (the then) Portsmouth Polytechnic dropped his cardboard box
of punch cards that made up his end of course project.

 

[Roy Smith]

I still remember the cry of anguish when the guy in the computer
building at (the then) Portsmouth Polytechnic dropped his cardboard box
of punch cards that made up his end of course project.

That's why you punch sequence numbers in columns 73-80. If the cards
get out of order, just run the deck through the sorter.

 

[Rustom Mody]

Rustom Mody wrote:


80 character was the hard limit.
The soft limit for readability is 60..65 characters.
Think about it.


Just that a language accepts
#define MASK_SEPIA_INTERNAL_BLEEDING_WASHINGTON_DC_BLACK 0x147800fa
means that it is a good idea to do so.

Yes there are fundamental but soft limits, eg
http://webtypography.net/2.1.2

And there are (semi)hard technological limits like if you post code longer 65
chars out here it will fold at random unforeseen points.
These limits get irrelevant as the technology changes.

If any of these has any relation with the magic number '79' I'd be
curious to know.

Until then may we relegate '79' to quaint historical curiosities like:
Continuation in 6th column, Comment is a C in 1st column, 7-72 for code
(ALONG WITH ALL CAPS CODE)?

 

[Steven D'Aprano]

And there are (semi)hard technological limits like if you post code
longer 65 chars out here it will fold at random unforeseen points. These
limits get irrelevant as the technology changes.

The technological limits may become irrelevant, but the human limits do
not. While there are no *hard* limits to readability, both excessively
long and excessively short lines are hard to read. Comprehension and
reading speed suffers.

If any of these has any relation with the magic number '79' I'd be
curious to know.

79 is one short of 80, which gives you a margin of error of 1: off-by-one
errors won't matter if you aim for 79 characters but miscalculate by one.

People repeatedly state that 80 is the old, obsolete hard limit for
ancient terminal systems, but the reason terminals standardised on 80
rather than 70 or 90 (or for that matter 300 or 30) is at least in part
-- and I maintain a big part -- because of human reading. 60 to 90
characters per line is a comfortable range for human readability, which
makes 80 a reasonable compromise that tends towards the upper end but
without pushing hard up against it.

Keeping the monitor size and character size fixed, it's easy to show
*fewer* characters per line if you choose a standard towards the upper
end, if you so choose, but impossible to squeeze in more if you choose a
standard at the lower end.

Just because the monitor (or the standard) *allows* up to 79 characters
per line doesn't make it a good idea to regularly use that many. In my
experience, given two or three indent levels, reasonably descriptive
variable names, decently expressive expressions, I find that 60-70
characters is *typically* enough horizontal space for the average line of
code. Long lines are often (not always) a sign that you're doing too much
in one line. This isn't Perl, and newlines are a renewable resource.

Until then may we relegate '79' to quaint historical curiosities like:
Continuation in 6th column, Comment is a C in 1st column, 7-72 for code
(ALONG WITH ALL CAPS CODE)?

Nope. Because the main driving force for 79 characters is not technology
but human reading.

 

[Mark Lawrence]

Not until the general capacity of human cognition advances to make
longer lines easier to read.

We humans may be historical curiosities some day; until then, let's
continue to write our code as though humans are the ones who will be
reading it.

I thought code was meant to be read by programmers, not humans

 

[Dave Angel]

That's why you punch sequence numbers in columns 73-80. If the cards
get out of order, just run the deck through the sorter.

And of course, don't forget to increment them by 10's, so you can insert
new cards without resequencing the remainder.

I recall having to buy two tapes, because the operators were very
resistant to taking several boxes of cards at one shot. (A box was 2000
cards) At that point, the card decks were instructions to the editor,
how to turn the version of the code on tape1 into the new version, to be
written to tape2. (And on every run, don't forget to reverse the lines
describing which tape is tape1 and which is tape2.)

 

[Johannes Bauer]

Not until the general capacity of human cognition advances to make
longer lines easier to read.

I find it surprising how you can make such a claim about the whole of
humanity (!) without even feeling the need to have a pro forma study to
back it up. Also, not everything that applies to prose also equally
applies to code.

Personally I find overly narrow code (80 cols) to be much *harder* to
read than code that is 100 cols wide. Keep in mind that even if the
break is at 100 cols, lines will rarely exceed that limit. And if they
do to *understand* the code, the further down the line it is the less
important are the details usually.

I don't know why anyone would force a display issue onto everyone. It
imples the arrogant stance that every human being has the exact way of
reading and writing code. Everyone can configure her editor to what she
wants (including line breaks and such).

If people were to force pixel sizes of editor fonts, everyone would
immediately recognize what a stupid idea this would be. Even though I
could claim that the vertical formatting is all messed up when you don't
display my code with the correct font size! Ridiculous, right?

Regards,
Johannes


--

Zumindest nicht öffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <[email protected]>

 

[Marko Rauhamaa]

I don't know why anyone would force a display issue onto everyone.

Well, if I have to work with your code, you are forcing your style on
me.

It imples the arrogant stance that every human being has the exact way
of reading and writing code. Everyone can configure her editor to what
she wants (including line breaks and such).

That's a good point: why aren't we just exchanging AST's and configuring
the editor to display them in our preferred format?

Well, we're not there yet.

Objective readability is not the main issue here, IMO. It's the screen
estate. I know the idea of "windows" is fast disappearing from modern
("mobile") computing; you have "apps" instead that commandeer the whole
screen. Personally, I find that a big step backwards. I want to be able
to subdivide the screen for many windows that represent different
contexts and tasks.


Marko

 

[Chris Angelico]

Personally I find overly narrow code (80 cols) to be much *harder* to
read than code that is 100 cols wide. Keep in mind that even if the
break is at 100 cols, lines will rarely exceed that limit. And if they
do to *understand* the code, the further down the line it is the less
important are the details usually.

The limit of human readability is generally given to be somewhere in
the range of 60-120. It's not a single specific value that's exactly
the same for everyone; personally, I like my lines of code to be a bit
longer than 80, and will happily go to 90-100, but in the interests of
interoperability, it's helpful to standardize on one common value -
especially for large shared codebases.

You're arguing against the specific value of 80, but 100 is still
pretty close to that. There are two key boundaries: the point at which
your eye can no longer comfortably read the text, and the point at
which you need to scroll horizontally. The latter of course depends on
your screen, but it's an EXTREMELY important barrier; the former is
the "soft" boundary, as you won't instantly know when you're over it.
(The two can be in either order, of course. I could easily read 90
char lines, but if I'm in a standard 80x24-25 terminal window, that's
going to scroll.) Both boundaries are almost certainly exceeded by a
500-character line; if you're doing your code like that, you obviously
do not want anyone reading it. [1] Whether you cut it off at 70, 80,
100, or some other figure, you still want to put some kind of limit on
it.

ChrisA

[1] That doesn't mean "never do this". I've sometimes had code with
insanely long lines - for instance, an auto-generated list of names -
and it wasn't meant to be human-readable. Breaking it onto multiple
lines would have complicated matters unnecessarily, and if you wanted
to read the code, you should be reading the other file anyway.

 

[Chris Angelico]

Windows 8/ Unity/ Gnome 3 are great on tablets (at least they look like
they should be the only one I can confirm is Win 8) but lousy on a full
pc with keyboard (Mouse optional)

I am with you & use either LXDE or XFCE or run level 3 on all of my
systems.

Sorry, I should clarify that I'm talking about desktop systems here. I
have no idea how good those UIs are on actual tablets; my beef with
them is that putting a tablet UI on a desktop is just as much a bad
idea as putting a desktop UI on a tablet. When I have a 1920x1080
display on a screen that's about a meter wide, running a single
application is seldom what I want to do.

ChrisA