Chas. Owens wrote:
> On Mon, Oct 27, 2008 at 20:28, Rob Dixon <[EMAIL PROTECTED]> wrote:
>> John W. Krahn wrote:
>>>
>>> The fewer lines of code to read and/or write, the easier it is to spot
>>> mistakes, the less chance for "action at a distance."
>>
>> Not at all.
>>
>> Is this
>>
>> sub wanted { return unless -f; open my $FH, '<', $_ or die "Cannot open '$_'
>> $!"; while ( <$FH> ) { /\Q$string/ && print $REPORT "$File::Find::name\n" and
>> return; } } find \&wanted, '/test';
>>
>> easier to debug?
>
> No, it is not, but it also isn't fewer lines of code; it is many lines
> of code compressed into fewer lines. Fewer lines of code means using
> higher level constructs (such as anonymous subroutines) to eliminate
> redundant code.
I think your distinction between 'lines' and 'lines of code' is unusual, and
what you seem to mean by 'lines of code' is synonymous with 'statements'.
I have a particular issue with statements like
/\Q$string/ && print $REPORT "$File::Find::name\n" and return;
which are ugly in the extreme and do not begin to read as English. The style
comes from Perl's origins on the Unix platform, and use of shortcuts like this,
that are familiar to Unix shell programmers, do nothing to help Perl's migration
to other platforms. The grep() function is a similar culprit - thank God there
is no sed() or awk().
My point was that John's reduction of what I believe should be
next unless /\Q$string/;
print $REPORT "$File::Find::name\n";
return;
to a single line (and line of code, and statement) does nothing to improve its
visibilty, or to support John's assertion that, "The fewer lines of code to read
and/or write, the easier it is to spot mistakes". Putting everything on one line
helps no one; grouping code to properly imply its function helps a lot.
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
