Is mostly a question of front-loading. What part of the statement seems the most important in its context? If we're just trying to avoid warnings about undef values, then adding if defined $foo to the end of a statement seems less obnoxious than putting the condition up front.When you need to add if defined $foo to the end of the statement it is often because of you do not know if the parameter is passed in case you use variable number of arguments to function or subroutine. As such it is a deficiency of the language, which currently does not allow defaults for parameters. May be
is slightly clearer is such casesmy $arg3=(defined($_[2]) : $_[2] : 0;
But if we're going to do a lot of processing on $line, then my $line = <$fh> or return; is probably clearer than return unless my $line = <$fh>;.I disagree. The line
return unless my $line = <$fh>;.to me is always preferable to
my $line = <$fh> or return;The latter is "idiomatic Perl" which I would recommend to avoid, as it is one of the reasons many people hate Perl. I think there are very few justified uses of this construct instead of if (and mainly by programmers with heavy experience in bash, where it is more natural ). For example
or($debug) && say "Line=$line";
($?>0) && warn('...');
In reply to Re^9: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by likbez
in thread What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by likbez
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |