Re: Practical example of "Is Perl code maintainable" (golf)

Reading your proposed code, I'd think you were shooting for a golf win rather than for maintainable code. I think you make a good case for the bad influence of "golf" on the ability of Perl coders to write maintainable code, which I'm certain is not something you want to do.

Here are some of your infractions against my personal list of best practices for Perl:

Never use implicit shift; always specify @_ as in shift @_.
Don't use logical operators in place of real flow control.
Don't hide flow control off to the right of a statement.
Don't write code that looks like it would be tripped up by Perl's "looks like a function" rule.
Avoid magic numbers like "2".
Use meaningful variable names (having no variable name means it can't be meaningful).

The original code is a bit verbose and demonstrates a lack of knowledge about list slices and a lack of confidence about list assignment in Perl. I'd certainly chop all of the trailing $dummys since that just adds noise. The rest of the code is at least acceptable and most of it I much prefer over your golfed version.

The most maintainable code I'd write would look more like:

sub file_mode
{
    my( $fileName )= @_;
    if(  ! -f $fileName  ) {
        return -1;
    }
    my( $dev, $ino, $mode )= stat( _ );
    return $mode;
}
[download]

or maybe

# The items returned by stat():
my( @Stat, %Stat );
BEGIN {
    @Stat= qw(
        dev     ino     mode    nlink   uid     gid     rdev
        size    atime   mtime   ctime   blksize blocks
    );
    %Stat{@Stat}= ( 0 .. $#Stat );
}

sub file_mode
{
    my( $fileName )= @_;
    if(  ! -f $fileName  ) {
        return -1;
    }
    my $mode= ( stat _ )[ $Stat{mode} ];
    return $mode;
}
[download]

Note that I didn't use File::stat because the BUGS section is unacceptable to me. ETOOMUCHMAGIC is such a common problem. I wish more Perl coders could learn to be proud of writing simple code, rather than so often nearly trying to invent a new language with each module in the apparent attempt to provide one's personal "perfect syntax" for expressing what the module is meant to address. It would have been better for File::stat to avoid overriding the name stat().

- tye

Comment on Re: Practical example of "Is Perl code maintainable" (golf) Select or Download Code

Replies are listed 'Best First'.
Re^2: Practical example of "Is Perl code maintainable" (golf) by eyepopslikeamosquito (Archbishop) on Aug 13, 2007 at 21:14 UTC
`my( $dev, $ino, $mode )= stat( _ ); return $mode; }` [download] I disagree with introducing the `$dev` and `$ino` variables here, given that they are not being used. Many languages will throw a "variable is initialized but never used" warning if you do that sort of thing. Apart from that, I feel it makes maintenance harder because the maintenance programmer has more variables to visually digest ... and then perhaps ponder why they are not being used. For similar reasons, I dislike capturing parens in regexes when the captured values are not being used; I find myself visually checking the code for `$1`, `$2`, ..., wondering if I've missed something.	[reply] [d/l] [select]
Re^2: Practical example of "Is Perl code maintainable" (golf) by xdg (Monsignor) on Aug 13, 2007 at 18:52 UTC
It would have been better for File::stat to avoid overriding the name stat() But easily avoided, since symbol pollution is optional. `use File::stat (); my $st = File::stat::stat( 'some_file' );` [download] -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply] [d/l]
Re^3: Practical example of "Is Perl code maintainable" (File::stat) by tye (Sage) on Aug 14, 2007 at 02:39 UTC
It is even easier to avoid it by not using the module at all. The amount of code required to replace the module is small enough that it is hardly worth using the module unless it provides a marked interface improvement, which it comes close to doing. Perhaps before Perl 5.8 it fully succeeded. And I think it would only require (any number of) minimal changes to the module for it to be generally useful to me. As is, it just misses the mark except in limited situations. Offering to export stat()/lstat() with non-conflicting names [Stat()/LStat()] and populate() with a better name¹ would certainly suffice. ¹ `StatHash(stat _)` ? Except File::stat doesn't produce a hash. It produces a Class::Struct object. So `$st= StatObj( -d ? stat _ : lstat ) for $fileName;`. - tye	[reply] [d/l] [select]
Re^2: Practical example of "Is Perl code maintainable" (golf) by eyepopslikeamosquito (Archbishop) on Aug 13, 2007 at 20:32 UTC
I think you make a good case for the bad influence of "golf" on the ability of Perl coders to write maintainable code, which I'm certain is not something you want to do. Yes. This reminds me of Twenty20 versus one-day versus test cricket or blitz (five-minute) versus traditional (five hour) tournament chess. Playing too much Twenty20/one-day cricket can be poor preparation for a test series, just as playing too much blitz chess can be poor preparation for a traditional chess tournament. To which I will add that playing too much golf can be poor preparation for traditional coding. :-) In my defence, I always follow the Perl Best Practices "Always unpack @_ first" advice for non-trivial subroutines. It's just that these two are so trivial, I couldn't resist writing them as one-liners.	[reply]


more useful options
	PerlMonks