Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: A desperate lunge for on-topic-ness

Reply
Thread Tools

Re: A desperate lunge for on-topic-ness

 
 
Evan Driscoll
Guest
Posts: n/a
 
      10-18-2012
Ooo, a good religious war. How could I resist? Bear in mind that
what I say is relative to layout issues, which in the grand scheme of
things. So even if I say I really disklike something, it's still not so
bad in practice. Except for backslash continuations.


On 10/18/2012 01:06 AM, Zero Piraeus wrote:
> What are people's preferred strategies for dealing with lines that go
> over 79 characters?


My general rules are:

1. I dislike 80 character limits, and basically don't make a
particularly strong attempt adhere to them for, well, basically
any code I write, Python or not. I'll explain a little bit of why
later. (I'd begrudgingly go along if I were working on a different
code base that did of course, but in the meantime I don't have to
deal with corporate style standards or anything like that so can
bend the rules a bit.) 100 about where I start getting
uncomfortable, and my semi-hard limit is 110-120. No doubt that's
because that's about the line length I get with half of my monitor's
width.

Python isn't as bad as C++ though (my main other language), where
80 characters can go by *very* quickly.

2. Backslash continuations are *terrible*. I hate them with a firery
passion. A line could be 1000 characters long and it would be
better than a 120-character line backslash-continued.

3. Using parentheses for continuations is sunshine and rainbows.

4. Extra variables are also great; I suspect I tend to use a
more-than-average amount of extra variables anyway. (Though
probably less so compared with the Python coder community than with
the C++ coder community.)


Hans Mulder said:
> Steven D'Aprano said:
>> 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,
> )


Ugh, I hate both. I really dislike the arguments to a function
appearing to the left of the function. I'm fine with either

some_function(foo,
bar,
baz)

or

some_function(
foo,
bar,
baz)

but the two quoted suggestion makes me cringe a bit. (Of my two options,
I think I actually prefer the latter, but tend to use the former because
I'm too lazy to figure out how to make Emacs do the second one.)

So with the above rule I might format that as:

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

except that runs afoul of another of my implict formatting "rules",
which is that if I have a multi-argument construct (e.g. an operator
or function call) and one of the arguments is multiple lines, I'd prefer
to see all of the arguments on their own lines. So I'd format
that as:

some_variable = (spam('x')
+ ham(a, b, c))

as my first choice (long var names truncated here, but in real code with
no indent that's only 76 characters with the full ones in so it's fine
-- I'd do it that way even with a couple levels of indent) and

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

as my second, even though they require an extra set of parentheses and
even though there is plenty of room on the first line for "foo +
foo(".


The reason I say I dislike the quoted suggestions -- and ultimately why
I really dislike the 80 character limit -- is the following. If you ask
proponents of the 80 character limit, they'll tell you about how there's
only so much horizontal space and stuff like that. But I think that
ignores the benefits you get from intelligently using *vertical* space,
and I think the quoted suggestions do too.

I've taken each of the suggested formattings of the above and turned
them into a graphic, which you can see at
http://pages.cs.wisc.edu/~driscoll/temp/indent.png

I've drawn the boundary of every valid subexpression (except for the RHS
of each assignment) in each of the versions. In my suggestions, the
"ham(....)" subexpression is always contained within a rectangle -- in
the quoted suggestions, it is not, and is a more complicated shape. It
seems to me that the relationship between the vertical and horizontal
layout in those examples is somewhat haphazard. I can't even come up
with a "rule" for how the quoted examples arose; for mine, I'd say I'm
trying to keep subexpressions together in space (both horizontal and
vertical). I'm not sure that "drawing boxes" is exactly the right thing
to say what I'm doing, but I think it at least serves to illustrate my
point in this case.

Evan


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQgCt2AAoJEAOzoR8eZTzg4bEIAJKo3P8zlG rGxlidUXaCfvma
mjoczG/zG31GIhgpGdnwPoUEg828B5xI7ADof3wdV4YV1m/iAveUqpphAMI7dhDW
0HGzM7RzNWvDN8osQ6Qn9JGSgDesRqWmWdNPuYkITJy+Caz8Zb YfI/YBX+tQUX6O
/zlCEbvjipEy1V3TFJ0e3JMj/pRJqqBIG0DuILoBWlidc/8CUlkRswgvf5spzDDt
9BVYWD9bI3fVYoIbRiiRJ5PPmJ4fjWjxTVShF6yLo5mQrXCizL f0EooStkzwVHel
N/JKtYfZRQIViqAHK4YFSpmPM6S/Y8Cwvt2YCTysmGL3sMHey+HV6sGjcvBdFqU=
=CjQf
-----END PGP SIGNATURE-----

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
A desperate lunge for on-topic-ness Zero Piraeus Python 24 10-19-2012 10:16 PM
Re: A desperate lunge for on-topic-ness Jean-Michel Pichavant Python 2 10-19-2012 05:59 PM
Re: A desperate lunge for on-topic-ness Mark Lawrence Python 0 10-18-2012 09:12 AM
Re: A desperate lunge for on-topic-ness Demian Brecht Python 0 10-18-2012 06:52 AM
Re: A desperate lunge for on-topic-ness Chris Angelico Python 0 10-18-2012 06:13 AM



Advertisments