The argument you're making is equally valid for other aspects of code quality. There are CPAN modules without adequate test packages, modules that have unnecessary version dependencies, and (of course) modules with bugs in them. And, as you say, there are modules that aren't documented well (or at all).
One might as well say that nothing should get into CPAN without a test suite that can be shown to have 100% coverage, or until after an explicit peer review.
On the other hand, no one is forcing you to use CPAN modules, and you still might get usable code or at least ideas from the submissions.
There is a self-serving reason for CPAN authors to write documentation, of course; if you have a popular module, you'll get a lot less email to deal with if you add documentation. My own modules are pretty well documented (Archive::Zip: 27% pod, Algorithm::Diff: 54% pod) but I still get questions asking me about various things. I try to address these questions in the next version of the documentation so that I don't have to answer the same emails again.
Then too, just because you have documentation in a module doesn't mean that people will read it (as evidenced by the number of answers here on PM that quote one bit or another from the manual).
In reply to Re3: CPAN documentation improvements
by bikeNomad
in thread CPAN documentation improvements
by InfiniteSilence
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |