Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

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

by tye (Cardinal)
on Aug 13, 2007 at 15:54 UTC ( #632243=note: print w/ replies, xml ) Need Help??


in reply to Practical example of "Is Perl code maintainable"

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:

  1. Never use implicit shift; always specify @_ as in shift @_.
  2. Don't use logical operators in place of real flow control.
  3. Don't hide flow control off to the right of a statement.
  4. Don't write code that looks like it would be tripped up by Perl's "looks like a function" rule.
  5. Avoid magic numbers like "2".
  6. 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; }

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; }

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
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' );

    -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.

      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 name1 would certainly suffice.

      1 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        

Re^2: Practical example of "Is Perl code maintainable" (golf)
by eyepopslikeamosquito (Canon) 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.

Re^2: Practical example of "Is Perl code maintainable" (golf)
by eyepopslikeamosquito (Canon) on Aug 13, 2007 at 21:14 UTC

    my( $dev, $ino, $mode )= stat( _ ); return $mode; }
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://632243]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (6)
As of 2014-07-25 03:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (167 votes), past polls