Re: mini-quiz
Ron Isaacson <Ron.Isaacson-/PgpppG8B+R7qynMiXIxWgC/[email protected]> Tue, 19 Jun 2007 00:44:58 -0400
| Newsgroups | gmane.comp.lang.perl.qotw.discuss |
|---|---|
| Message-ID | <[email protected]> |
Joshua Kronengold wrote:
>
> >> my $country = map +(/^(?:|gbr)$/ ? '' : uc),$card->country;
>
> [...] is much better.
>
> I have the privledge of working at an organization that cultivates an
> intermediate (or better) knowledge of perl (which the first construct is
> solidly in the middle of, using nothing (expression-level map, regular
> expressions) an intermediate perl programmer should be completely
> comfortable with). If I were writing for a basic or worse programmer to
> maintain, I might expand it, but that would make it harder for an
> intermediate-or-better perl programmer to maintain.
Sorry, but you lost me there. I consider myself to be a pretty darn
good perl programmer, and even I'd have to read that line a few times
to understand its meaning.
if ($country eq 'gbr') {
$country = '';
} elsif ($country ne '') {
$country = uc "[$country]";
}
I'm sure someone will find a way to clarify it even more, but to me,
that's a one-pass read and the meaning smacks you over the head.
You're honestly telling me this block would be HARDER for an expert
programmer to maintain (i.e., tweak if the desired logic changes
slightly) than your one-line version above?
> All things being equal, shorter -is- better. Any phrase that goes much
> over a page becomes increasingly harder to comprehend -- and both
> "advanced" expressive features of a language like perl, and object
> oriented programming are techniques in furtherance of this (among
> others) goal -- to divide a proogramming task into byte sized chunks
> that are comprehensable and debuggable on their own.
Yes, I agree about chunks, although one byte might be a bit too small.
;-)
I think part of the philosophical debate centers around what's
important in your environment (something that will be different for
all of us). Is your company's mission to produce concisely-written
perl programs that make the best possible use of the language's
features? If so, then what you've done might be great. But my
company's mission is to do something else entirely, and an expert
understanding of the nuances of the perl language by all of our
developers wouldn't necessarily help us accomplish that mission.
I suppose the most important thing for any technology (including a
programming language) is to apply it in a way that's appropriate for
the problem it's intended to solve and the environment in which it
will be used. As with everything in PBP, IMHO the best thing you could
learn from this thread is not that there are right or wrong ways to
write this particular piece of code (which we could clearly debate ad
nauseum), but that within your particular environment, you should
consider factors such as the importance of readability and conciseness
when developing your own personal style.
--
Ron Isaacson
Morgan Stanley
ron.isaacson-/PgpppG8B+R7qynMiXIxWgC/[email protected] / (212) 762-1950