A desperate lunge for on-topic-ness

Z

Zero Piraeus

:

Okay, so, first thing vaguely Python-related that comes to mind [so
probably not even slightly original, but then that's not really the
point]:

What are people's preferred strategies for dealing with lines that go
over 79 characters? A few I can think of off the bat:

1. Say "screw it" and go past 79, PEP8 be damned.

2. Say "screw it" and break the line using a backslash.

3. Say "well, at least it's not a backslash" and break the line using
parentheses.

4. Spend 45 minutes trying to think up shorter [but still sensible]
variable names to make it fit.

5. Perform an otherwise pointless assignment to a temp variable on the
previous line to make it fit.

6. Realise that if it's that long, it probably shouldn't have been a
list comprehension in the first place.

Any I've missed? Any preferences?

-[]z.
 
S

Steven D'Aprano

What are people's preferred strategies for dealing with lines that go
over 79 characters? A few I can think of off the bat:

1. Say "screw it" and go past 79, PEP8 be damned.

I've been burnt enough by word-wrapping in editors that don't handle word-
wrapping that well that it makes me really uncomfortable to go over 78-79
characters, even by only 1 extra. So I don't like doing this.

Just about the only time I go over is if I have a comment that includes a
URL with more than 78 characters. I hate breaking URLs more than I hate
breaking the 79 character limit.

2. Say "screw it" and break the line using a backslash.

Low on my preference list, but occasionally.

3. Say "well, at least it's not a backslash" and break the line using
parentheses.

I mostly do this. Since most lines include a bracket of some sort, I
rarely need to add outer parentheses just for the purpose of line
continuation.

some_variable = spam('x') + ham(
some_longer_variables, here_and_here,
and_here_also)

I know PEP 8 says I should drop the final round bracket to the next line,
but I don't normally like that.

4. Spend 45 minutes trying to think up shorter [but still sensible]
variable names to make it fit.

Ha! Since most of my variable names are already relatively short, that's
not often much help.

5. Perform an otherwise pointless assignment to a temp variable on the
previous line to make it fit.

Hardly ever.

You missed one:

5a. Perform an assignment to a temp variable that you really should have
done anyway, but reducing the number of characters in the line was the
impetus that finally made you act.

6. Realise that if it's that long, it probably shouldn't have been a
list comprehension in the first place.

What if it wasn't a list comp in the first place? :)

Refactoring code makes most long lines go away on their own.
 
R

rusi

:

Okay, so, first thing vaguely Python-related that comes to mind [so
probably not even slightly original, but then that's not really the
point]:

What are people's preferred strategies for dealing with lines that go
over 79 characters? A few I can think of off the bat:

It really depends on whether one is programming for learning, as a
profession or publicly (as on this list).

The third is necessary to say because mailers are going to break long
lines.
As for the other two, there is a distinction because:
For example, a candidate C-programmer would be expected to show
prowess with pointers in an interview that would be frowned upon when
he professionally develops in C for production.
 
P

Paul Rubin

Zero Piraeus said:
2. Say "screw it" and break the line using a backslash.

Often the line will break ok without a backslash, but I don't feel any
particular pain in using a backslash in the other cases.

I do pretty rigorously try to keep all lines shorter than 72 columns or
so, unless there's a long literal like a url. Even such a literal would
probably only occur in throwaway code. Any specific url in
longer-lasting code should probably be read from a configuration file
rather than being hard coded.
 
H

Hans Mulder

I mostly do this. Since most lines include a bracket of some sort, I
rarely need to add outer parentheses just for the purpose of line
continuation.

some_variable = spam('x') + ham(
some_longer_variables, here_and_here,
and_here_also)

I would spell that as:

some_variable = spam('x') + ham(
some_longer_variables,
here_and_here,
and_here_also,
)
I know PEP 8 says I should drop the final round bracket to the next line,
but I don't normally like that.

I normally put the final bracket on the next line, where it is
very visible. Compare:

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here, and_here_also):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

vs.

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here,
and_here_also,
):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

Which one would you say is more readable?


-- HansM
 
W

wxjmfauth

Le jeudi 18 octobre 2012 11:07:25 UTC+2, Hans Mulder a écrit :
I would spell that as:



some_variable = spam('x') + ham(

some_longer_variables,

here_and_here,

and_here_also,

)







I normally put the final bracket on the next line, where it is

very visible. Compare:



if looks_like_it_might_be_spam(

some_longer_variables,

here_and_here, and_here_also):

logger.notice("might be spam")

move_to_spam_folder(some_longer_variables)

update_spam_statistics(here_and_here)



vs.



if looks_like_it_might_be_spam(

some_longer_variables,

here_and_here,

and_here_also,

):

logger.notice("might be spam")

move_to_spam_folder(some_longer_variables)

update_spam_statistics(here_and_here)



Which one would you say is more readable?





-- HansM

I use a "double indentation".
.... 'asdf' and 'asdf' and \
.... 'asdf' and 'asdf':
.... print('do if')
.... s = 'asdf'
.... ss = 'asdf'
....
do if.... some_longer_variables,
.... here_and_here, and_here_also):
.... logger.notice("might be spam")
.... move_to_spam_folder(some_longer_variables)
.... update_spam_statistics(here_and_here)
....
Traceback (most recent call last):

jmf
 
C

Chris Angelico

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here, and_here_also):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

This wants different indentation levels for the condition and the
code. That'd make it readable enough.

ChrisA
 
Z

Zero Piraeus

:

There seems to be a consensus [to the extent there ever is, anyway]
around using parentheses etc., then ...

I've been burnt enough by word-wrapping in editors that don't handle word-
wrapping that well that it makes me really uncomfortable to go over 78-79
characters, even by only 1 extra. So I don't like doing this.

I have to admit, I try quite hard not to exceed 78. I don't know why
[never been bitten by badly behaved editors], but something about 79
characters in an 80-char window makes me uncomfortable.
Just about the only time I go over is if I have a comment that includes a
URL with more than 78 characters. I hate breaking URLs more than I hate
breaking the 79 character limit.
Agreed.

You missed one:

5a. Perform an assignment to a temp variable that you really should have
done anyway, but reducing the number of characters in the line was the
impetus that finally made you act.

Ah. Yes :)

I use a "double indentation".

... 'asdf' and 'asdf' and \
... 'asdf' and 'asdf':
... print('do if')
... s = 'asdf'
... ss = 'asdf'

Actually, I had a follow-up question about indentation planned. I used
to double-indent, but am now more likely to go with e.g.
.... arg1,
.... arg2,
.... arg3
.... ):
.... do_something()

as others have suggested. An alternative would be something like
.... arg2,
.... arg3):
.... do_something()

which I like much less. I have to admit, though, that all the original
options make me feel a little dirty except (#4) "shorter variable
names" [which just makes me feel that I am being overly precious] and
(#6 generalised) "this needs refactoring" [which I would say includes
Steven's #5a].

-[]z.
 
T

Tim Chase

I use a "double indentation".

... 'asdf' and 'asdf' and \
... 'asdf' and 'asdf':
... print('do if')
... s = 'asdf'
... ss = 'asdf'
...
do if
... some_longer_variables,
... here_and_here, and_here_also):
... logger.notice("might be spam")
... move_to_spam_folder(some_longer_variables)
... update_spam_statistics(here_and_here)

I lean towards double-indent as well, though I favor parens/brackets
vs. trailing backslashes. My conditions usually go one-per-line,
too. I also tend to put my closing paren+colon on a stand-alone line:

if (
something
or something_else
or yet_other_stuff
):
do_thing1()
do_thing2()

It's not quite as nice with pure parens, working better with
function-calls. However, it makes my git/svn diffs easier to read
when conditions get added/removed because only that line (usually)
changes, rather than having the noise of the paren moving around.

In 2.5 and later, I like to write that as

if any([
something,
something_else,
yet_other_stuff,
]):
do_thing1()
do_thing2()

where each item is uniform (one trailing comma, rather than one item
being special without a comma/or/and) so I don't have the diff noise
for "or"/"and" bouncing around either.

Making my diffs easy to read is pretty important to me.

-tkc

PS: and in such cases, yes, I often alphabetize my conditions too as
long as the order doesn't matter. Just a little CDO. That's OCD,
but in alphabetical order the way the letters should be :)
 
G

Grant Edwards

What are people's preferred strategies for dealing with lines that go
over 79 characters? A few I can think of off the bat:

I try to do what's easiest to read and understand. Sometimes that
means using a line thats 120 characters long, sometimes that means
breaking up the line.
 
D

Den

:


What are people's preferred strategies for dealing with lines that go

over 79 characters? A few I can think of off the bat:

I personally just keep typing until my statement is finished. This is my program, not PEP's.

But I have to say I'm amused by the whole question, and others related to PEP8. A quick aside, the width of our roads all go back to the width of a two horse rig. The suggested maximum of 80 characters goes back to teletypemachines, and IBM cards, and character based terminals

Should that really be the basis for a suggested style now?

Den
 
D

Den

:


What are people's preferred strategies for dealing with lines that go

over 79 characters? A few I can think of off the bat:

I personally just keep typing until my statement is finished. This is my program, not PEP's.

But I have to say I'm amused by the whole question, and others related to PEP8. A quick aside, the width of our roads all go back to the width of a two horse rig. The suggested maximum of 80 characters goes back to teletypemachines, and IBM cards, and character based terminals

Should that really be the basis for a suggested style now?

Den
 
N

Neil Cerutti

But I have to say I'm amused by the whole question, and others
related to PEP8. A quick aside, the width of our roads all go
back to the width of a two horse rig. The suggested maximum of
80 characters goes back to teletype machines, and IBM cards,
and character based terminals

Should that really be the basis for a suggested style now?

I had to use vim's reformatting powers to fix your first
paragraph. ;)

http://www.codinghorror.com/blog/2006/06/text-columns-how-long-is-too-long.html

Code is limited to one column, is left-justified, and
comprehension is much more important than reading speed. There
are lots of studies, but they are all about blocks of text, not
code.

Though technology has moved along swiftly, keeping your code
accessible to the guy using a crummy old console xterm might
still be worthwhile, and it makes printouts easy to create.
 
C

Chris Angelico

Though technology has moved along swiftly, keeping your code
accessible to the guy using a crummy old console xterm might
still be worthwhile, and it makes printouts easy to create.

And keeping your interface accessible to someone who can't use the
Home and End keys allows it to be used by someone who's using PuTTY on
Windows to SSH to a gateway and then SSH from there to a firewalled
computer that's running your application. And yes, I do exactly that,
and yes, for some reason Home/End don't always work. One day I'll
probably figure out what the issue is, but for now, I'm just glad
there are baseline text editors that don't need such keys...

Technology moves on, but not everywhere.

ChrisA
 
G

Grant Edwards

I personally just keep typing until my statement is finished. This
is my program, not PEP's.

But I have to say I'm amused by the whole question, and others
related to PEP8. A quick aside, the width of our roads all go back
to the width of a two horse rig. The suggested maximum of 80
characters goes back to teletype machines, and IBM cards, and
character based terminals

Should that really be the basis for a suggested style now?

You don't expect me to through my Heathkit H19 terminal in the trash,
do you? :)
 
P

Prasad, Ramit

Hans said:
I would spell that as:

some_variable = spam('x') + ham(
some_longer_variables,
here_and_here,
and_here_also,
)


I normally put the final bracket on the next line, where it is
very visible. Compare:

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here, and_here_also):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

vs.

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here,
and_here_also,
):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

Which one would you say is morereadable?

For the first example, I would probably indent the arguments more
to differentiate a continuing line. That way the "):" does not
look like it was un-indented to be part of a different block.

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here, and_here_also):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)


Ramit Prasad



This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
 
P

Prasad, Ramit

Den said:
I personally just keep typing until my statement is finished. This is my program, not PEP's.

But I have to say I'm amused by the whole question, and others related to PEP8. A quick aside, the width of our
roads all go back to the width of a two horse rig. The suggested maximum of 80 characters goes back to teletype
machines, and IBM cards, and character based terminals

Should that really be the basisfor a suggested style now?

Den

Unlike IBM cards and the teletype, character based terminals are still
widely used (at least in the developer communities). They often default to
80 characters, but handle various sizes. So that comparison is not quite
fair.

Ramit Prasad

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
 
P

Prasad, Ramit

Chris Angelico wrote:
And keeping your interface accessible to someone who can't use the
Home and End keys allows it to be used by someone who's using PuTTY on
Windows to SSH to a gateway and then SSH from there to a firewalled
computer that's running your application. And yes, I do exactly that,
and yes, for some reason Home/End don't always work. One day I'll
probably figure out what the issue is, but for now, I'm just glad
there are baseline text editors that don't need such keys...

Technology moves on, but not everywhere.

ChrisA
--

Home and end do not bother me much as I can usually use ctrl+a/ctrl+e
for the same purpose. I do wish I found a better way to page up/down.


Ramit Prasad

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
 
Z

Zero Piraeus

:

[...] I'm amused by the whole question, and others related
to PEP8. A quick aside, the width of our roads all go back to the
width of a two horse rig. The suggested maximum of 80 characters goes
back to teletype machines, and IBM cards, and character based
terminals [...]

.... and the decisions made back in the day about line length on
teletypes etc. were informed [perhaps unconsciously] by the rules of
printed literature - and *those* rules have a *lot* of accumulated
wisdom behind them.

Robert Bringhurst's Elements of Typographical Style is very good on
that stuff; one thing he points out is that, at root, what's
comfortable is defined by the size of the human hand, the distance we
hold a book from our eye, etc. ... and while we still live in a world
composed of physical objects, a lot of that gut feeling about what's
comfortable carries across into the digital world.

The accepted rule in print is that lines of prose should be between 45
and 90 characters, with 66 being ideal for readability. Code is not
prose, and the combination of fixed-width and much more variable line
length aids readability, but however it came about, ~80 does seem to
more or less work as a limit.

I'm pretty slavish about adhering to PEP 8 these days. Programmers are
an opinionated bunch, and we all, given the opportunity, will come up
with our own set of obviously [goddammit] correct rules. Having a
broadly sensible, authoritative set of guidelines that we grudgingly
agree to follow makes working with other coders easier IMO.

-[]z.
 
G

Gene Heskett

You don't expect me to through my Heathkit H19 terminal in the trash,
do you? :)

Or me to delete the vt-220 I wrote to run on a TRS-80 Color Computer
running OS-9 for an OS, 20 years ago when the Dec made one ate its H.O.T. &
Dec would not sell me a H.O.T. since it was over 5 years old and wanted
$2995 for brand new vt-550 (with no guarantee it would be compatible)?

That, and their field service engineers inability to fix a crashing hourly
or more PDP-11/723a amply explains why DEC is no longer with us.

That single obstinate computer made the CBS tv network design a new system
and distribute it gratis to every network affiliate they had, somewhere
around 125 stations, at a cost of at least 10G's a station.

Screw that. I had better things to than throw more good money after bad.
So did CBS at the time.

Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
How sharper than a hound's tooth it is to have a thankless serpent.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top