Re: Perl::Critic Tests

["R. Ransbottom" <..hidden..>]

Don't do this, please.  

That is Perl novice thinking which shows a poor understanding of Perl's 
definition--and use of--context.

The bare return is a basic building block of some standard and 
simpler Perl idioms.

If we promote bad standards of coding we will discourage the better
coders from joining in on our projects.  


On Sat, Apr 22, 2017 at 07:37:25AM +0100, Nick Prater wrote:

> Matt Trout raised an issue that this policy leads to surprising 

> sub get_value {
>      return;
> }
> my %hash = (
>      row => get_value(),
>      id  => 1
> );
> print Dumper \%hash;
> ----
> 
> which returns:
> $VAR1 = {
>            '1' => undef,
>            'row' => 'id'
>          };

Matt forgot to 'use warnings;'.  Ouch!  Had me going for a minute.
That example has nothing to do with the bare return statement.

Witness:

    %h = ( "george" );  

gives  "george" => undef  and warns

> I prefer an explicit "return undef;" as I think it's clearer, more 
> obvious about the intention and less magical. Eric suggests we problably 
> want to switch from "no return at all" to "return undef".

The problem with this expression of intent is that it is buried at
the bottom of a function that someone wants to use not to read.  

The return statement is designed specifically to be handy when returning
nothing in list or scalar context.  I suppose the basic example is:

sub filter_things {
    if ( $it eq "good" ) {
        return $it;
    }
    return;
}

When you use such a function to build up an array the bare return returns
an empty list.  So you are not building large arrays with useless elements,
so don't have to skip over them in processing, and so this works:

    if_or_while ( @array ) { more_to_do(); }

because you did not return a list with one undefined element but returned
an empty list.

If you don't use this basic idiom, i.e. the duplex nature of bare return,
then there is little point to using RequireFinalReturn.  This what a final
return is meant to do.

> I therefore propose that we do not enforce the 
> ProhibitExplicitReturnUndef policy and will add a comment to the tests 

If we are not enforcing the policy we can just drop it from our suite.

> Thanks to k-man and dcg_mx for initiating and sharing the discussion 
> with Matt Trout.

Thanks,
Rob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel