Perl best practices

Ben Scott dragonhawk at gmail.com
Mon Sep 17 22:16:53 EDT 2007


On 9/13/07, Paul Lussier <p.lussier at comcast.net> wrote:
> For all those just tuning in, Ben and I are in violent and vocal
> agreement with each other, and at this point are merely quibbling over
> semantics :)

  Hey, now, I came here for an argument, and I demand to get one!  And
it better be more than just simple contradiction, too.  I expect a
connected series of statements intended to establish a proposition!
;-)

  (And they say Perl and Python have nothing in common.  ;-)  )

> To avoid LTS and backslashitis in a regexp, I tend to do something like:
>    m|/foo/bar|/bar/baz|g;

  The pipe (|) is another often-used regexp syntax character, though.
If I was going to use a single alternate character for m//, I'd prolly
use a bang (!).  But I like balanced pairs -- {} or or [] or <> or ()
-- because they nicely identify the start and end of the thing, rather
than simply delimiting it.  And if it's a substitution, they let you
separate the pattern from the replacement with whitespace.  I
frequently use that to line things up for visual structure (e.g., that
condense_type() function I posted).

> Agreed, though, we ... do things like this slightly differently,
> completely avoiding the $_ dilemma:

  That actually wouldn't work for the code I posted, which is
performing multiple transformations on the same string repeatedly.
The fact that you missed that concerns me.  *That's* a sign of
inadequate clarity.  Looking at the code, I don't see a way to make
that clearer in the code itself, so I guess it needs a comment to that
effect.  Phooey.  (In my thinking, ideal code needs *no* comments,
because it's so obvious what's going on.  Obviously, that's a
theoretical ideal, and not something that happens in practice, but I
think it makes a good goal.)

  Unrelated to the above, I think there is an observation to be made
here about "sophisticated" solutions also adding complexity.  KISS, as
the saying goes.  By introducing variables and loops and control
structures, you're making things more complex, to no gain that I can
see.  A simple list of s/// operations does the same thing, and does
not require any additional cognition on the part of the reader.  (It
might even be more efficient at runtime, although that would depend on
how smart Perl's optimizer is.)

> ... by we, I mean the company which currently puts food on my table ...

  I didn't know Stop and Shop used Perl...  ;-)

> Once readability has been achieved, the next
> priority ought to be future maintenance and extensibility, IMO.

  Yup.

> Alas, assertNumArgs() is a part of a huge
> home-grown library of routines we have.

  Everybody has these.  They're extremely useful.

>>> The compelling argument is this: It should be blatantly obvious to
>>> whomever is going to be maintaining your code in 6 months what you
>>> were thinking
>>
>>   I do not think I could agree with you more here.  The thing you seem
>> to be ignoring in my argument is that "clarity" is subjective and
>> often depends on context.  :)
>
> I'm not ignoring it.  I'm saying that where you have stopped because
> you think it is sufficiently clear can in fact be made cleaner and
> clearer for the sakes of both clarity and future maintenance.

  No, I'm saying that clarity is subjective and depends on context,
and what you deem "clearer" I deem "less clear".

> There are only a finite number of options for any given command [such as tar].  The
> same is not true for writing perl code.

  True, but I think my point still stands.  Verbosity does not equal
clarity, and indeed, verbosity sometimes interferes with readability.

  (My choice of tar was, perhaps, a bad example, because I do agree
with your argument WRT to your AMANDA example.)

-- Ben


More information about the gnhlug-discuss mailing list