Since Perl Best Practices has been published, some of its module recommendations have become out-of-date with current community best practices.

This list goes over each module recommended by PBP and provides some commentary, either agreeing or disagreeing with the recommendation.

Modules from CPAN

Attribute::Types

No. Perl's attribute system is problematic in many, many ways (?). Use things like Moose and Params::Validate instead. For objects use Perl's own type system.

Class::Std and Class::Std::Utils

No. If you want to use inside-out objects, Damian himself now says you should use Class::InsideOut or Object::InsideOut instead. Better yet, consider using Moose, which provides a more featureful and complete OO system for Perl. To his credit, Damian's book started quite a flury of debate and interest in Inside-Out objects. It's unfortunate that paper books can't capture the changes of opinion and the state of the art after it's published.

Config::General

Yes. Apache like syntax for configuration - good for passing configuration onto non-programmers. Also an easy to write data serialisation language, although one element arrays can be tricky to specify.

Config::Std

Maybe, using in large-scale production code and works flawlessly. If you start anew, be sure you have seen Moose before making a decision.

Config::Tiny

???

Contextual::Return

Maybe no. Perl context is complex. If you do not feel comfortable distinguishing what context you call your subroutines/methods, this module may cause you more harm than good. OTOH, if you did master your contextual homework, this module will ease your API and code. But before using this module please make sure you are aware of the bugs (see CPAN RT) and it's sub-optimal maintenance.

Data::Alias

Yes. This is useful.

After the line:

alias my $watch = $person{name}{pocket_contents}{watch};

You can use "$watch" instead of the easy to mistype "$person{name}{pocket_contents}{watch}".

DateTime

Yes. This is the standard Perl class for datetime handling. See Recommended DateTime Modules.

DBI

Yes. This is the standard Perl class for talking to databases. See Recommended Database Modules.

Devel::Size

Yes.

Exception::Class

Yes.

Fatal

No. Fatal has been completely superseded by autodie which provides better error messages, a rich exception mechanism, and lexical scoping. Unless code needs to run on a release of Perl before 5.8.0, or must only depend upon historical core modules, then the use of autodie is recommended over Fatal.

File::Slurp

Yes. (although dealing with UTF8 strings is not documented in the module and this can result in errors under some circumstances).

Filter::Macro

No. Source filters are not worth the trouble. There are often other ways to achieve the same goals anyway.

Getopt::Clade

No. Vaporware - basically admitted by the modules author himself, who recommends to use Getopt::Declarehttp://search.cpan.org/search?module=Getopt::Declare or Getopt::Euclid instead. Both modules seem to worth a look.

Getopt::Euclid

Mostly yes. It generally works well. Tucked away in the docs is a description of the :vars option which makes it export variables in the same was as many other getopt modules for more details. Use it like this:

use Getopt::Euclid qw(:vars<opt_>);

In my (perhaps limited) experience this is the best of the "just write POD to implement option processing" modules. I may also be biased as I implemented the :vars option for Damian.

Two relatively minor issues are that it wants to handle other arguments, not just options, and that error reports (when the user runs the program with invalid arguments) can be a little obscure, depending on the nature of the error. Both could be fixed with a little love, which I guess Damian doesn't have time to give at the moment.

HTML::Mason

Yes, but also look into proper MVC frameworks like Catalyst. You can use Mason as the templating engine with Catalyst or other frameworks. See Web Frameworks.

For pure templating consider Template Toolkit.

Inline

Maybe. Having separate XS files isn't that hard, and reduces the amount of magic in your distro.

IO::InSitu

???

IO::Interactive

???

IO::Prompt

Maybe. Works great on Unix, but fails on Windows (although it installs on Windows), no test suite (only "use_ok" and POD tests)

Lexical::Alias

???

List::Cycle

Not likely. Andy Lester wrote List::Cycle as an example of how to write an inside-out module after reviewing early drafts of the book. It's effectively sample code posted to the CPAN. It does the same thing as Tie::Cycle without using the tie mechanism.

List::MoreUtils

Yes, although you might want to look at Util::Any

Log::Stdlog

No. Use Log::Dispatch or Log4Perl instead.

Module::Build

Maybe. There's a lot of controversy in the Perl community about Module::Build. But it is preferable to ExtUtils::MakeMaker, which is discouraged even by its own maintainer.

Module::Starter

Yes. Much better than h2xs.

Module::Starter::PBP

Maybe. Lots of CPAN authors don't follow Damian's guidelines, but they're certainly better than nothing.

only

???

Parse::RecDescent

Maybe. A brilliant module, but very slow, so it may not be suited for many tasks. Despite its author, the module's interface and documentation conspicuously fail to follow many of the 'best practices' in the book. Which may be due to the fact that it was written well ahead before the book.

Perl6::Builtins

No. It provides only little syntactic sugar, doesn't provide similar syntax to Perl 6, has open bugs and not been updated since 2005.

IPC::System::Simple and autodie both provide a 'system() or die' syntax, except both can do the dying for you (with rich exceptions and error messages), and autodie allows you to change it with lexical scope.

Perl6::Export::Attrs

Maybe. Some want to use Sub::Exporter instead. Others find Perl6::Export::Attrs just fine and much less hassle than Sub::Exporter.

Perl6::Form

???

Perl6::Slurp

Maybe not, handy syntax, but has issues with utf8.

POE

Yes

Readonly

Maybe There are a number of people who don't like it because it uses tie internally (which is forbidden by the book). However, if you also install Readonly::XS, this issue goes away for scalars. The counter arguments against the constant pragma are in the book.

Regexp::Autoflags

???

Regexp::Assemble

Yes Surprisingly fast, even for huge regular expressions. A good alternative to the other techniques in PBP to improve the readability and purpose of regexes.

Regexp::Common

Yes. Very handy for finding numbers in various formats, URLs and other stuff for which hand-made regexes are notoriously wrong.

Regexp::MatchContext

???

Smart::Comments

No. Absolutely not, at the very least because it's a source filter. No functionality is worth a source filter under any circumstances. There is no such thing as a safe source filter.

The only exception would be to do as Sinan Unur mentioned on StackOverflow:

I prefer not to put:

use Smart::Comments;

in my code. When I do indeed use Smart::Comments, I invoke the script using:

$ perl -MSmart::Comments test.pl

This way, there is no chance Smart::Comments will be used in production code.

Sort::Maker

???

Sub::Installer

No. Use Sub::Install (note the missing -er) or for more complex installation, Sub::Exporter.

Text::Autoformat

Yes. This is very handy module, and there's really nothing else like it on CPAN.

Text::CSV

Yes. Provides a unified interface to Text::CSV_XS and to a pure perl implementation if the XS module is not available.

Text::CSV::Simple

Yes. The interface of Text::CSV is somewhat cumbersome, and this provides a saner interface for the common task of reading a file.

Text::CSV_XS

Yes.

XML::Parser

No. This API is too arcane and complex for user code to call directly. Other modules, some built on top of XML::Parser, provide a better interface. If you want a DOM-style interface, check out XML::LibXML. If you want a SAX interface, check out XML::SAX. If you want to make a big data structure from an XML document, use XML::Simple. Also take a look at XML::Twig.

YAML

Maybe. If you just need to dump and load YAML, use YAML::XS which is faster, less buggy and implements YAML 1.1. Though JSON, i.e. JSON::XS, Config::General may be preferable as a simple serialization format.

Since the page represents a single opinion, whose opinion is this? "The community's"?

contributed by Michael Schwern on Sep 10 3:44pm

It's a community effort - if somebody encounters a "Yes" and disagrees, he makes it a "Maybe". If somebody sees outdated information, she updates it. --moritz