On Thu, May 21, 2009 at 11:01 AM, Ben Finney <firstname.lastname@example.org>
Jeremiah Dodds <email@example.com>
On the contrary, I find that *much* easier to grasp than the same
> hmm, the 80-character convention does not stop me from unconsciously
> writing really complex list comprehensions, I just write them like so:
> def foo(f, a, b, c):
> return [[((f(x,y) * i, i) if i % 2 else 0)
> for i, x in enumerate(a)
> if f(y, x) == a + x]
> for y in [c(z) for z in range(a, a*b+c, c)]]
> not that that's really any better.
statement on a single line. You have been required, by choosing to
follow the 80-column limit, to choose points at which to break the line;
and have responded by breaking it up into conceptually discrete chunks
and indented to suggest the structure.
This example is, for me, a very convincing (anecdotal) demonstration of
why an 80-column limit is a good constraint to follow.
Oh, yes - I consider it much easier to read than the single-line equivalent. What I meant by "not that that's really any better" was more along the lines of "that statement should probably be refactored". It's very rare that I run into a case where a convoluted list comprehension like that isn't better written some other way. Sometimes I end up with stuff like that when I've made incorrect assumptions while designing a program, etc.
Yet it's also more than that; to call it “personal taste” is to imply
> But yeah, this is all anectodal evidence and personal taste, as
> Raymond points out.
that it's nothing more than aesthetics. If that's all it were, I'd care
far less for changes in convention.
I consider it rather more importantly a matter of software ergonomics,
which should therefore not be changed unless there's good supporting
evidence that the proposed change results in improvement.
I tend to agree. That's very well-said.