When scanning CPAN in that "Surely there's a better way" mode, I use some heuristics (read:prejudices) which roughly sort modules into the good, the bad and the kooky.
I'll search in the problem area, pop tabs for each module, then kill tabs based on the feeling I get from the docs. I'm talking about modules that do address your problem, but in such a poor way that you're better off without them.
I'm interested other peoples red-flags during this
initial appraisal. Obviously, they're not absolute
and will vary according to the general problem and
specific context.
Update: The answers so far have largely been too
sensible and rational. Express your inner bigot.
To start out, here's some I've managed to untangle
from that "blargh" reaction.
Red Flags:
- Any of the usual code red-flags which are noticable from the module's docs: it reinvents wheels, uses globals, magic numbers, ... These have been done elsewhere.
- Massive, nested structures passed into new().
- It's callbackwards. Requiring an entire callback architecture when a few more methods would do.
- It parses pseudo-perl data structures or expressions.
- big_procedure_names_containing_pseudo_arguments
- It has a "send email" option.
- Or more generally, the "but wait there's more..." interface. I can use the Extra::SteakKnife module myself, thanks.
- It's general purpose templating ignorant.
- Names like EZBlah, or HTML::* (Well, I am more skeptical in the HTML:: namespace than in B::)
- Tied tightly to a given architecture/set of modules. Double red-flag if I'm anti the prerequisites.
- The language is uncomfortable with perl terms: we pass in what is known as a "Hash Reference"...
- Notes on portablility, standards compliance.
- Intelligent notes on bugs, limits, caveats, subclassing
- Version numbers and updates, some features marked still experimental.
- Super-star author.
- XS version of some critical routine