[tpm] Seeking advice on using Perl in a professional way
ceeshek at gmail.com
Thu May 4 19:00:09 PDT 2017
Following on with Alex's suggestions, perl has wonderful tools for writing
tests for your code, but command line scripts can be notoriously difficult
to test. If you treat everything as a class or object it can give your
code better structure and separation, but it can also greatly simplify your
Have a look at MooseX::App. It gives you a nice framework for handling
command line options, and treats your command line app as an object. It
will also automatically build your --help output for you. Using Moose will
also allow you to write much cleaner and more expressive code.
On Thu, May 4, 2017 at 8:41 PM, Alex Beamish <talexb at gmail.com> wrote:
> Hi Harold,
> 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
> > wrote:
>> 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
> Alex Beamish
> Software Developer / https://ca.linkedin.com/in/alex-beamish-5111ba3
> Baritone, Board Member, Toronto Northern Lights, 2013 Champions /
> Certified Contest Administrator, Barbershop Harmony Society /
> toronto-pm mailing list
> toronto-pm at pm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the toronto-pm