Doubles: it found files in blib as well as the original, of which some were symlinks to files in lib (or similar). My first run was faster than yours, but I noticed that when you add the numbers from the objects of the analysis, the __END__ docs and such are not taken into account for the whole file, which is why I analyze twice: once for the whole file (lines of docs and comments and total lines in the file) and once per object (lines of code). Another slowdown is because of the SHA256, as files might get copied (no link or symlink).
It is an interesting project though. Have you tried it on your site_perl? For me it crashes halfway with some weird error (after running for 15 minutes), but then again, I do have 2118 modules installed, resulting in 12151 .pm files and 900 .pl files. That'll take a while to complete.
Enjoy, Have FUN! H.Merijn
| [reply] |
Ah, it sounds like you are using it on all modules already installed on the machine. I'm only using it on a single distribution downloaded with cpanm --look which just downloads the raw module from cpan without installing it. So I have no blib directory. Yeah, I noticed the SHA256 in your code. I'm sure that's what makes it a bit slower. Not a big deal. I was just trying to figure out why mine was slower for you. Sounds like my code was probably slower for you because it was analyzing many files twice.
| [reply]
[d/l]
[select] |
I was thinking of turning this into a simple CPAN distribution, maybe Distribution::Inspector or something like that. It would provide a command like cpan-inspect which would download the module and issue a report on the distribution for someone wishing to assess the module. It might provide useful information that could help a developer more quickly determine the health/quality of a distribution.
| [reply]
[d/l]
[select] |
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)
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.
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l]
[select] |
| [reply] |