Alternative title: Modulism - Code Bigotry
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
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.
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.
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"...
It's not all bad, the above often have converse
. Here's some more:
Notes on portablility, standards compliance.
Intelligent notes on bugs, limits, caveats, subclassing
Version numbers and updates,
some features marked still experimental.
XS version of some critical routine
So what have I missed?