[tpm] Seeking advice on using Perl in a professional way

[Cees Hek]

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
tests.

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.

Cheers,

Cees


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
> transformation.
>
> 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
> unnecessary.
>
> 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
> handy.
>
> Cheers,
>
> Alex
>
>
> 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.
>>
>> Thanks,
>> Harold
>>
>> _______________________________________________
>> toronto-pm mailing list
>> toronto-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/toronto-pm
>>
>>
>
>
> --
> Alex Beamish
>
> Software Developer / https://ca.linkedin.com/in/alex-beamish-5111ba3
> Baritone, Board Member, Toronto Northern Lights, 2013 Champions /
> www.northernlightschorus.com
> Certified Contest Administrator, Barbershop Harmony Society /
> www.barbershop.org
>
>
> _______________________________________________
> toronto-pm mailing list
> toronto-pm at pm.org
> http://mail.pm.org/mailman/listinfo/toronto-pm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/toronto-pm/attachments/20170504/38674fd9/attachment-0001.html>