Re: mini-quiz

At 09:44 PM 6/18/2007, Ron Isaacson wrote:
>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?

I think the sweet spot is in between (pretty much the original two lines).

It's not that the first line contains anything that can't be understood 
by a decent programmer.  It's how long they take to read and understand 
it.  And it's not that the second one isn't perfectly clear.  It's how 
much screen real estate it takes up.

I am in the middle of refactoring a program written by someone else who 
might have thought they were getting paid by the line.  Their 2400 line 
program was nigh incomprehensible even though it used nary a complex 
construct.  Why?  Because it consumed so much space that it was 
impossible to see the forest for the trees, and of course there were no 
comments explaining what it was doing.  I've gotten it down to 600 
lines (mostly by factoring out massive amounts of mind-numbing 
duplication) and am now beginning to figure out the purpose.  That 
program will be much clearer when I get it to 300 lines than it was at 
2400.  (It really isn't doing anything that needs more than 300 lines 
and I would rewrite it from scratch much faster if I only knew what its 
requirements were, but those aren't written down either so I have to 
figure them out from the code!)

IIRC, Jon Bentley has a great example in Programming Pearls, about a CS 
class exercise that had a simple and elegant solution.  A few people 
who didn't spot the simple solution solved it the corporate way, with 
huge comment blocks explaining every variable and statement in 
nauseating detail, and were outraged that he downgraded them for 
following "best practices".  His retort was that those practices are 
only useful when they clarify the code and not when they obscure it.

Shrink too much, of course, and you end up with selfgol.  So you back 
off.  The second option above contains two tests for the value of 
$country and two assignments to it, and the reader has to parse each 
one mentally.  That makes me look for something that reduces those 
numbers without making it more obfuscated than it's worth.
-- 
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com/
http://www.perlmedic.com/