[tpm] Seeking advice on using Perl in a professional way
talexb at gmail.com
Thu May 4 17:41:43 PDT 2017
Always glad to chime in on this kind of stuff.
For production scripts, apart from the code being as solid as possible
(more later), the most important thing is to add in consistent logging. Log
when the script starts, when it finishes, and whenever anything significant
is found. And check those logs regularly for anything odd.
My current bunch of scripts are moving data around, so I've made undefined
variables fatal, so as to catch the unwanted undef -> '' or 0
By all means use PerlTidy on your scripts during development -- it allows
your eyes to easily absorb lots of detail, and doesn't affect performance
at all. Using strict and warnings is very important as well. The code
should be clean, clean, clean. Perlcritic is also good, but I don't agree
with all of Damian's recommendations -- ignore the warnings you think are
Where to put POD is usually open to debate, but I prefer it all at the
bottom, rather than interspersed with code, because I like to see as much
code at once as possible.
Finally, this may be heresy in this group, but I'm not a fan of making
everything into an object. I can build a HoH or AoH to do just about
anything I need, and in my current assignment I've been using AoH's with
each element containing a code ref to get stuff done. Very neat, and very
On Thu, May 4, 2017 at 8:24 PM, Harold Tessmann <htessmann at control-tec.com>
> Hi from Michigan! Apologies if that’s a little far away for the Toronto
> list, but the local pm.org mailing lists seems a little dead.
> I'm looking to productionize some Perl scripts, and as such, I want to
> adopt more structure than I use in disposable scripts. These scripts would
> be used within the bounds of my employer, not released to the general
> public (with maybe one or two exceptions). I know that TIMTOWTDI, but I
> like the “sometimes consistency is not a bad thing either” extension when
> it comes to common problems such as command-line option parsing, and the
> perldocs don’t go in depth on what people use in the real world. I’m
> looking for advice on topics including, but not limited to:
> • Modern Perl: I like it in general, and I can install it on my team’s
> machines. Are there reasons I shouldn’t use it?
> • Does anybody have a suggestion for a good blank script template? For
> instance, I know I want "use Modern::Perl 'version';" or "use
> warnings/strict;", etc., but there’s probably other things I would want in
> a basic script. I’ve handled this in a sort of ad-hoc manner, growing new
> scripts based on what I learned from the old, but I’d like to build a good
> template once and be done with it. I’d also like the template to include
> documentation, and that raises more questions. Is there a reason to put my
> pod block near the top vs. the bottom? Getopt::Tiny seems nice, including a
> feature to automagically build a usage block—should I use that or is there
> a reason to avoid it? Or is there a better option parser?
> • Do you run Perl::Critic on your code? I know I’ll disable some of the
> rules, but is it more hassle overall than it’s worth? Similarly, PerlTidy:
> it seems useful for generating HTML versions of documentation, but I write
> code in a very precise way, such it would take more time to configure it
> than I would save in reformatting.
> • Thus far I haven’t built anything complicated enough to warrant figuring
> out an object library; I can get by with basic hash-based structures. I’ve
> read a bit about Moose and Dancer: how do they compare? And what else is
> widely-used that I should consider?
> Any advice is greatly appreciated.
> toronto-pm mailing list
> toronto-pm at pm.org
Software Developer / https://ca.linkedin.com/in/alex-beamish-5111ba3
Baritone, Board Member, Toronto Northern Lights, 2013 Champions /
Certified Contest Administrator, Barbershop Harmony Society /
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the toronto-pm