5 minimums for any perl script?

[Greg McCarroll]

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.

Concerns/risks.

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.

G.


On 29 Jan 2012, at 21:02, Leo Lapworth wrote:

> Hi,
> 
> 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+?)
> 
> Mine:
> 
> 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?
> 
> Leo