On 2010-10-22, Jean-Michel Pichavant <jeanmic...@sequans.com> wrote:
>> I'm all for descriptive names, but there's a great deal of benefit to
>> knowing when a descriptive name will help, and when all you need is a
>> variable which will be quickly recognized.
>> Compare:
>> [theValueInTheList.func() forTheValueInTheList in theList]
>> [x.func() for x in list]
>> One of these is much, much, easier to read than the other. It's
>> not the one that used a "descriptive" name.
> You did not use descriptive names in your example, but verbose names.
> That makes a huge difference.
Well, they certainly describe the objects in question better.
> [ str(day) for day in week ]
> [ str(x) for x in _list]
> [ str(d) for d in w ]
> I let you decide which one is better. After that I'm running out of
> arguments :o)
This is an interesting example! I would probably use str(x) for x, because
the idiom of using "x" trumps the details of what we think x is in a
particular case, but I do like "week" better than "_list", certainly.
Unless, of course, we have context:
def strings(week):
[ str(day) for day in week ];
In that case, I'd think that
[ str(x) for x in list ]
would be much clearer.
In general, I don't like to use single-letter abbreviations unless they're
consistent as part of an idiom. I'm fine with "s" for a string, "e" for
an exception, or "i" for an index. I wouldn't normally use "d" for a day,
because that's not a convention. (There's similarity to pronouns; pronouns
are great, but you can't usually just invent new ones.)
> Note that I did not suggest to write
> [ aDayInAWeek.displaymeCauseImAwesome() for aDayInAWeek in
> weekContainingSomeDaysHopefully ]
Heh.
I think one thing that's been somewhat missed is the importance of
surrounding context.
I would have no problem with:
except KeyError, e:
print "How on earth did we get a KeyError:", e
exit(1)
or something similar. (Ignoring, for now, the issues with "exit(1)".
If we had a much larger and more complicated bit of processing, much
of which didn't use or refer to the exception, and then came back to it,
though, I might prefer a name which will be easier to track:
except KeyError, e:
# time to get clever!
new = alternative_list()
new = [x.fixup() for x in new]
if new.size > 3:
more_complicated()
stuff_here()
else:
and_now_a_little_song()
...
...
...
else:
print "I couldn't recover, sorry.", e
I'd find that much less attractive, because at that point, e is no longer
really working like a pronoun; it's not a common thread throughout the
execution, but a reference to context some distance previously, and it
hasn't been maintained. So a big part of the question, for me, is how
regular and consistent the usage is. I don't mind i for a loop index for
something that's heavily using i. I don't mind it for something where
i is never used at all inside the loop, just as a counter. But if there's
a large complicated bit of processing, with a single reference to "i"
buried in the middle of it, then I'm going to want to replace it with a
name that tells you what it is.
The tradeoff there is largely a question of what it's like to read the
code. If reading the code makes the variable's usage obvious, a one-letter
name may be appropriate, especially if the variable's meaning is really
nothing more specific than "that thing we're working with".
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
