5 minimums for any perl script?
greg at mccarroll.org.uk
Sun Jan 29 22:26:23 GMT 2012
I'm afraid i'm going to be boring and suggest some business requirements.
In comments or pod, note the following:
When you are doing this (even if version control can tell people), and who you are.
Why? if there is a long worded document/spec, at least give its name. Check it in under version control even if your BOFH growls at you.
Who for? Sales, accounting, etc. Name them.
Basically build up a context of why you are about to unleash this script on the world that today might be a one off, but next year might be a nightly cron job.
On 29 Jan 2012, at 21:02, Leo Lapworth wrote:
> I've been asked what would be a good minimum to have as a coding police
> for a company that isn't focused on Perl, but uses it occasionally. So if
> Perl Best Practices is too much, and you could only have 5 rules for any
> perl script, what would they be?
> (let's assume recent 5.10+?)
> 1) use strict; use warnings;
> - obvious why
> 2) all files to be perl tidied (ideally automatically)
> - it makes reading code easier, as long as there is a standard
> 3) All variable names to be clear about what they contain, no short
> variable names unless in a small loop (e.g. $i)
> - "But I know $e means...." doesn't help me in reading code
> 4) use Path::Class and always keep files/dirs as Path::Class objects
> as long as possible
> - this is a strange one, but it's more about being consistent and having
> $file->slurp; $file->openw() $dir->mkpath(). It seems to make code
> cleaner, others have
> suggested IO::Any, but that still has missing / odd behaviour for my
> liking at the moment
> 5) Always ask one other person to review your code
> What would yours be?
More information about the london.pm