P is for Practical | |
PerlMonks |
Re: Choosing the right moduleby afoken (Chancellor) |
on Oct 22, 2022 at 22:25 UTC ( [id://11147600]=note: print w/replies, xml ) | Need Help?? |
A side note: LWP::Simple is a wrapper around LWP::UserAgent. Here is how I choose new modules from CPAN. This is my way, it works for me, it is full of biases, unfair, not formalized, and probably wastes some time. I usually start with the docs. Present just the default skeleton and a synopsis of nothing more than use This::Junk::Module; and your module is out, no matter how excellent it might be. I want to see at least a few lines of code for some basic usage. I want at least some error handling. Preferably, something like "all functions die() on error, use eval BLOCK or Try::Tiny to handle errors", especially when I need to call a lot of functions. Also, the version number should not be 0.01 or 1.00. I look at the tests. Testing just that the module loads without errors, or even no tests at all is almost as bad as having no usable documentation. I expect that at least some of the tests are usable examples for using the module. I look at the source code. I expect to find mostly clean indenting, comments explaining non-obvious stuff, good names for variables and functions. I expect to be able to understand at least some relevant parts of the code at first sight. I look at the dependencies. I prefer modules that don't require half of CPAN plus 20 3rd party libs just to save three characters in a line of code that runs once every thousand years. Modules that just depend on core perl or really common modules are ranked up. And of course, I simply try the module if it survived that filtering process. If I can't get a hello-world example running within a few minutes, I drop that module and try the next one. Sometimes, there is not much choice. Probably the most prominent example is DBI. DBI is excellent and the de-facto standard for accessing any kind of database from Perl. Older standards are gone and replaced by compatibility layers, like Oraperl (replacing special-built perls with Oracle OCI compiled in) or Win32::DBIODBC (replacing the old Win32::ODBC). Alexander
-- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
In Section
Seekers of Perl Wisdom
|
|