|Pathologically Eclectic Rubbish Lister|
Re: Returning undef: The point I would like Damian to reconsiderby shmem (Chancellor)
|on Jun 22, 2007 at 12:43 UTC||Need Help??|
Don't change subroutine results based on list or scalar context.
Why? I have useful subroutines that produce data and behave different in void, scalar and list context:
and I don't see that as a bad practice. Works like expected and is documented. The alternative would be to shove the result explicitly through three other subs:
which gains me what exactly? Perl is context aware, even builtins do change their result depending on context, eg localtime. Why should I avoid perl's dwimmery? Should I avoid localtime and roll my own?
update: I have PBP on my shelf as well, and my biggest critic to it is about its title. It should have been named "Damian Conway's Coding Style", or "Perl Pitfalls" subtitle "and how to avoid them", or even "Code Perl Robustly" subtitle "without knowing all of perl".
My biggest critic upon Perl::Critic is that it enforces PBP's bad title as a standard, and where it could help you it doesn't, and will never: it can't tell whether you know what you are doing or have fallen into a trap, since it can't read your mind.
update 2: Personally I think that the rule "Use a bare return to return failure" cannot be a rule, since its text omits context. It's just bad worded and should be:
To return failure, use a bare return in list context, undef in scalar or void context. Set $@ to something meaningful.Perl::Critic should handle the rule that way.