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