<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div><br></div><div>Cees</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 4, 2017 at 8:41 PM, Alex Beamish <span dir="ltr"><<a href="mailto:talexb@gmail.com" target="_blank">talexb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Harold,<div><br></div><div>Always glad to chime in on this kind of stuff.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div><br></div><div>Alex</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, May 4, 2017 at 8:24 PM, Harold Tessmann <span dir="ltr"><<a href="mailto:htessmann@control-tec.com" target="_blank">htessmann@control-tec.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div style="font-size:13px">Hi from Michigan! Apologies if that’s a little far away for the Toronto list, but the local <a href="http://pm.org" target="_blank">pm.org</a> mailing lists seems a little dead.</div><div style="font-size:13px"><br></div><div style="font-size:13px">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:</div><div style="font-size:13px"><br></div><div style="font-size:13px">• 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?</div><div style="font-size:13px"><br></div><div style="font-size:13px">• 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?</div><div style="font-size:13px"><br></div><div style="font-size:13px">• 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.</div><div style="font-size:13px"><br></div><div style="font-size:13px">• 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?</div><div style="font-size:13px"><br></div><div style="font-size:13px">Any advice is greatly appreciated.</div><div style="font-size:13px"><br></div><div style="font-size:13px">Thanks,</div><div style="font-size:13px">Harold</div>
</div>
<br></div></div>______________________________<wbr>_________________<br>
toronto-pm mailing list<br>
<a href="mailto:toronto-pm@pm.org" target="_blank">toronto-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/toronto-pm" rel="noreferrer" target="_blank">http://mail.pm.org/mailman/lis<wbr>tinfo/toronto-pm</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-1905518437736706331gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Alex Beamish</div><div dir="ltr"><br></div><div dir="ltr"><span style="font-size:small">Software Developer / </span><span style="font-size:small;background-color:rgb(246,246,246);color:rgb(51,51,51);font-family:helvetica,freesans,"liberation sans",helmet,arial,sans-serif"><a href="https://ca.linkedin.com/in/alex-beamish-5111ba3" target="_blank">https://ca.linkedin.com/in/<wbr>alex-beamish-5111ba3</a></span><br></div><div dir="ltr">Baritone, Board Member, Toronto Northern Lights, 2013 Champions / <a href="http://www.northernlightschorus.com" target="_blank">www.northernlightschorus.com</a></div><div dir="ltr">Certified Contest Administrator, Barbershop Harmony Society / <a href="http://www.barbershop.org" target="_blank">www.barbershop.org</a></div><div><br></div></div></div></div></div></div></div></div></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
toronto-pm mailing list<br>
<a href="mailto:toronto-pm@pm.org">toronto-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/toronto-pm" rel="noreferrer" target="_blank">http://mail.pm.org/mailman/<wbr>listinfo/toronto-pm</a><br>
<br></blockquote></div><br></div>