All the Perl that's Practical to Extract and Report

The Perl Book Litmus Test

koschei on 2001-10-04T01:38:36

From the site "One Minute Perl Book Reviews", which mysteriously vanished at some point since the release of Camel 3:

The Perl Book Litmus Test

Remember, the point of this test is to find bad books and there can only be negative results with this test. A book which passes all the tests put forth here CAN STILL SUCK.

Flip to the index. Look up the following tidbits and answer the questions.

  1. localtime
    Does it state that it returns the number of years since 1900? Does it mention that when used in scalar context it returns a nicely formated date?
  2. srand
    Check how it uses srand(). Does it warn you to call it only once in a given program? (If srand is never mentioned, that's okay)
  3. Number of elements in an array
    Does it say that an array will return its number of elements in scalar context, or does it use $num = $#array + 1;
  4. flock
    Does it discuss and use flock instead of lockfiles? (ie. setting some .lock file instead of using flock().) It's okay if file locking is never discussed at all.
  5. Portable Constants
    When performaing flocking, socket operations or sysopens does it define it use the constants defined by Perl, or do they define their own unportable constants? (It's okay if the book never has to use these constants at all)

All very inspiring. Generally good. I suspect it could do with some refinement though.

  1. uses -w and use strict
    Any program in a book about Perl should be using examples that use warnings and strict. If, for some reason, the code needs to run without strict, it should be clearly noted why (and should probably just have part of the code wrapped in a no strict "refs"; ... use strict "refs"; pair.
  2. Doesn't have redundant code
    As I'm writing this, I'm looking at Programming the Perl DBI and most of the examples end in exit;. This isn't done for any apparent purpose. Like Strunk might have said had he written The Elements of Programming instead of The Elements of Style, "Omit needless code".
  3. Error checking
    The code should be checking for errors. Perl DBI does this generally wonderfully. All calls to functions that may return an error are trapped with "or die" (and when doing transactions it includes a rollback).
  4. In general, the code should not be red flaggable
    MJD has a series of articles about programming red flags: big alerts that something is wrong and that the program should pull into the pit stop. Ideally the programs shouldn't exhibit behaviour like the programs he plays with (well, not the originals that is). I think his articles cover what I want to say quite elegantly.

If all Perl books were like this then the world would be a happier place. Of course, there's still all those existing programs and the people who learn their Perl from them rather than books. Can't win 'em all =)