A desperate lunge for on-topic-ness

[Evan Driscoll]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20121018/76e84935/attachment.sig>