On 14/07/07, chromatic <[EMAIL PROTECTED]> wrote:
On Saturday 14 July 2007 12:57:37 Paul Cochrane wrote:
> I realized a while after having written my last email that I lost a
> bit opportunity in sending such a short reply: to actually *learn*
> something and to improve my skills with Perl. I shall attempt to take
> that opportunity now if you have the time and patience for me.
Sure thing!
Cool! Thanks! :-)
> > I don't trust some of these, and it makes me question the utility of this
> > coding standard test.
> I don't think we should blame the test, rather the implementer of the
> changes.
The test promotes adding explicit code to do nothing in certain cases. In my
mind, that's a mistake. It's like the "no declarations in conditionals"
rule. Sometimes that's correct, but the test as written requires us to add
extra code not to do the wrong thing.
I understand your point better now. So, there are places in the code
where an explicit return is correct and would be useful (e.g. when the
last line of a sub is just a variable name without an assignment, or
just a plain HEREDOC) and places where it isn't useful. In the first
case we need to add the explicit return, and in the second case we
need to decorate the code with ## no coda <P::C policy>. This has the
added benefit of pointing out to people like myself (who often think
too simply) that it was intended for the sub not to have an explicit
return. We can then reduce/remove the Perl::Critic warnings and still
have code perform the way it was intended.
There are instances where the C<new()> method just ends in a C<bless>
statement. Is it a good idea in such situations to explicitly return
from the bless?
An instance would be like this, (from lib/Parrot/IO/Capture/Mini.pm)
sub TIEHANDLE {
my $class = shift;
bless [], $class;
}
sub PRINT {
my $self = shift;
push @$self, join '', @_;
}
Is changing "bless [], $class;" to "return bless [], $class;" worth
the while? My gut feeling is that it's a *tiny* bit clearer what's
going on, but should one add an explicit return in this case? The
same goes for the C<push> statement within the C<PRINT> sub.
The best way to know for sure what we ought to expect is to get a
comprehensive test suite for this code and then make sure it looks sane.
Ok, this is probably a better place to start than trying to tick off
various coding standards warnings.
Many thanks for your reply, I do appreciate it :-)
Paul
