Please go ahead. But note that not everybody will use it in the same way. I'd use it from my development folder, which holds sources and builds. I use cpan (not cpanm) but others may use different ways/tools/means.

My script now hold - but does not report - also the information of the sub-analysis, which opens up to things like average LOC per sub/method and average lines-of-comment per sub/method. Problem in that is that this analysis does not include the docs that surround them or docs of the subs embedded in the main doc, possibly after the __END__, so any ratings from this module will be subjective.

Personally I am not a big fan of blank lines, but does that have any impact on the quality of the code? Neither do I use a lot of comments, but I think my subs/methods are well documented in the main docs. Is that of influence on your ratings? Should it?

In my tests I found one file with non-standard ratings:

 subs   lines     LOC    doc  blank  File
----- ------- ------- ------ ------  ---------------------------------
+-----
  260     307     260      2      7  ... (hidden)
[download]

That is 1.15 lines of code per sub/method :)

The "doc" says 2 lines, but all I see is one single line of comment that tells me the file is generated.

It might provide useful information that could help a developer more quickly determine the health/quality of a distribution

See also:

• Module::CPANTS::Analyse - Generate Kwalitee ratings for a distribution
• CPANTS Testing Service
• Improving the quality of my modules
• Writing Solid CPAN Modules

Updated: Added links to: CPANTS Testing Service, Improving the quality of my modules, Writing Solid CPAN Modules

Though very useful, these provide more objective qualitee/kwalitee information about a release.

The suggested inspector is something about statistics, and th interpretation of statistics is subjective.

e.g. A release might have full documentation that is way better than the docs of any other module on CPAN, but it is delivered in a high standard set of pdf/odt/docx/html/pod/man separate from the .pm file itself icluding a search engine, a graphical fully configurable Wx/Tk GUI just for the docs and ... (ok, I'll stop, just let your fantasy do the job here). As .pod is detected by M::C::A but *not* by the suggested introspection. Next to that, this new analysis just looks at the number of code/comment/blank/doc lines, not at their content, nor at the spelling or the completeness of covering the actual code. It is completely up to the user to weigh the given numbers. You just cannot come to a guide of what is healthy. I therefor think this new suggested module is fun but (for now) lacks real use for indicating quality.

<shameless plug>See also Release::Checklist</shameless plug>


Enjoy, Have FUN! H.Merijn