5 minimums for any perl script?

Sam Kington sam at illuminated.co.uk
Mon Jan 30 15:40:08 GMT 2012

On 30 Jan 2012, at 15:26, Paul Johnson wrote:
> On Mon, Jan 30, 2012 at 03:00:00PM +0000, Sam Kington wrote:
>> One problem with perlcritic is that many of its rules, out of the box, are silly and annoying. You need to do a fair amount of tweaking to stop it bitching about stuff you don't care about, before you can get to the bits where it's actually useful. Here's $WORK's standard perlcriticrc:
> I wouldn't argue with most of those (though I don't use perlcritic
> myself anyway) but
>> # Checking return values is a good thing. Checking the return value of
>> # close or print STDERR is downright silly.
>> [InputOutput::RequireCheckedSyscalls]
>> functions = :builtins
>> exclude_functions = print close
> could you explain why you think checking the return value of close() is
> silly?  I tend to have the opposite opinion.

In the code that we write at $WORK, any filehandle we close tends to be a log file or something, so adding extra boilerplate to our close statements would just be annoying.

Similarly, if we've managed to open a random file on the local filesystem for output, it seems slightly silly to check the return value of print every single time. If it was going to fail, it would have failed on the open call; adding boilerplate to every subsequent print statement just makes the code verbose and messy for no good reason.

If we were doing anything at all intricate, regularly, then yeah, I'd re-enable this warning. But for simple filehandles on a local filesystem, IMO it's overkill.

Website: http://www.illuminated.co.uk/

More information about the london.pm mailing list