develooper Front page | perl.perl5.porters | Postings from May 2000

Re: Thoughts on maintaining perl

From:
Ben_Tilly
Date:
May 25, 2000 12:28
Subject:
Re: Thoughts on maintaining perl
Message ID:
OF469885EB.687DCAEC-ON852568EA.006A9EEE@trepp.com
Chris Nandor wrote:
> At 13.31 -0400 2000.05.25, Horsley Tom wrote:
> >You may get the idea: You can be a perfectly competent
> >programmer, writing perfectly wonderful perl code
> >and it can *still* be virtually impossible for someone
> >else to maintain.
>
> I dunno, I am not sure I buy it.  Can you give us an example of
> well-written Perl code that would be very difficult for another
reasonably
> competent Perl programmer to maintain?

The full example would be long, so I won't include it here, but I will
describe an issue I ran across.  I had to learn some code written by
an old Lisp fan.  He had to deal with a table of data, each column of
which needed its own formatting and validation rules.  So he had a
hash of information about each column, one field of which had a key
called "format" which was the anonymous subroutine to format that
field correctly.  So you had a construct that looked like this:

  print join ",", map { &{$field_info{$_}{format}}($deal) } @fields;

It took me some time to figure out what that construct meant and where
the actual formatting information was.  His argument was that this was
a perfectly fine thing to do.  He did it all of the time, and it
allowed you to separate presentation from content.  He admitted that
the first time you saw it, it looked a bit strange, but if you knew
what it did...

That turned out to be a good lesson for me.  This construct really was
integral to his style, and once I got past the shock of that line it
really was maintainable.  You had a very well defined section of the
code that was straight configuration information, and a different
well-defined section of the code that was logic, and then the magic
bit that combined them was very short, and almost never was what you
had to change.

But I still believe that the above construct is either something you
do consistently or something you should never try at all.  Either
declare it part of the learning curve or else avoid it.  But do not
randomly subject people to it...

Cheers,
Ben

PS I later rewrote this to a faster and simpler form:

  my @field_subs = map {$field_info{$_}{format}} @fields;
  # time passes
  print join ",", map {&$_($deal)} @field_subs;




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About