Finding Unused Subroutines, but with PPI
Can I find all unused Perl subroutines with PPI? Ovid tried it with a quick shell script, which is probably good enough for his purposes, and certainly shorter than my solution.
I don't know if I've covered all of the cases, but it seems to mostly work.
I'm the author of Mastering Perl, and the co-author of Learning Perl (6th Edition), Intermediate Perl, Programming Perl (4th Edition) and Effective Perl Programming (2nd Edition).
Thanks for this. I started a messy project for general discovery and graphing for legacy CGI projects which is here: http://sourceforge.net/projects/codewalker/
Inspired by this and PPI in general, I'm thinking about taking another run at it. Thanks again, Hugh Barnard
There's always
perlcritic --single UnusedPrivateSubroutines, if its assumptions are what you want.If not, this policy might be a good starting point to roll your own. The policy uses a
Perl::Critic::Documentrather than aPPI::Document, but the former is easily manufactured from the latter.(Sorry I'm not good at English)
Thank you for your good post, always.
I tested the above code and it seems that the code fails to catch sub calls in the form of "foo()".
And, if target code has no sub call form "&...", this script dies with:
Can't use string ("") as an ARRAY ref while "strict refs" in use at D:\Temp\find_unused.pl line 42.
Thanks, I've fixed the two problems that you've noted. The death came from my use of
@{ ... }. If the thing inside is not an array ref, as in the case offindreturning no elements, the dereference fails. I just need a default, so I have@{ ... || [] }I left out the bits to find calls in the form of
foo(). I've re-added that.Thank you, Brian! This will be a very useful addition to my toolbox.
I tried to run your latest revision and it appears that it still does not recognize any call that uses parentheses, e.g. fubar() ?
Dumping the output of
gives me an undef which possibly why @list will always be empty?Thanks!
Nice, It would be nice to see it as part of PPIx::EditorTools.
Would you do it? If not, do you mind if I add it?
My answer for all new projects for the rest of this year is "No", so I guess that means you get to do it. It is open source, after all. :)
And, you get to fix the bugs too. :)
I just noticed this. It's a lovely bit of code. You mention that it's longer than mine, but it has a couple of strong advantages: it handles comments correctly and can easily be extended to other uses.