79 chars or more?

[Almar Klein]

On 17 August 2010 18:43, AK <andrei.avk at gmail.com> wrote:

> On 08/17/2010 12:21 PM, Stefan Schwarzer wrote:
>
>> On 2010-08-17 17:44, AK wrote:
>>
>>> On 08/17/2010 10:28 AM, Stefan Schwarzer wrote:
>>>
>>>> I'd probably reformat this to
>>>>
>>>>            self.expiration_date = translate_date(
>>>>              find(response, 'MPNExpirationDate').text,
>>>>              '%Y-%m-%d', '%m%d%Y')
>>>>
>>>> or even
>>>>
>>>>            self.expiration_date = translate_date(
>>>>              find(response, 'MPNExpirationDate').text,
>>>>              '%Y-%m-%d',
>>>>              '%m%d%Y')
>>>>
>>>> for consistency.
>>>>
>>>> This not only limits the width but also makes the nesting of
>>>> the calls more visible.
>>>>
>>>
>>> Doesn't this create the problem of functions growing too long to fit in
>>> a screen? I think it's very useful to try to keep function size low
>>> enough so that you can view the whole function without having to scroll
>>> up and down. (even though that's not always possible) -ak
>>>
>>
>> I think I'd extract some part of the function into a new
>> function then. In my opinion, the reasoning is similar to
>> the case, "Can't I use two spaces per indentation level?
>> That way I don't run so easily into the right margin if I
>> have more than five indentations in a function." ;-)
>>
>
> I think to some extent it's a matter of taste. I bet most people would
> agree that on the balance, 2-space indentations makes code much less
> readable, despite saving a bit of space.
>
> But let me ask you, would you really prefer to have:
>
>
>             self.expiration_date = translate_date(
>>>>              find(response, 'MPNExpirationDate').text,
>>>>              '%Y-%m-%d', '%m%d%Y')
>>>>
>>>
> (or the 4-line version of this above), even when it necessitates
> creation of a new function, rather than have this code on two lines?
>
> After all, I think it's a matter of balance between readability,
> expressiveness and succinctness. If I split a function in two, that
> still means that understanding the functionality of the code will
> require scrolling around and looking at the second function. I guess
> what I'm trying to say that we shouldn't just care about readability of
> lines but also readability of functions and blocks of functionality
> (that may include several functions that accomplish a single "task".)
>
>  -andrei
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>


I am in favor of the 80-char limit also. Besides the arguments listed above,
when using an IDE it gives you that extra horizontal space to fit some IDE
specific tools (such as source structure).

I must admit that I'm sometimes slightly frustrated when an expression is
JUST 81 chars, and I *need* to reformat to two lines. On the other hand,
very long lines are hard to read also. I guess the limit must be placed
somewhere, and for historical reasons, 80 chars makes the most sense IMO.

On a related note, why is the limit mentioned in PEP8 79 chars, and not 80?
I never understood this :)

Cheers,
  Almar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100817/b85376e9/attachment-0001.html>