Re: Perl Analyzer?

Have you tried B::Lint?

What do you mean by "subs that are declared and never used"? Do you mean a prototype without the actual sub or sub that's present but never referenced?

I suspect that autoloader would make it difficult to determine whether a used module's sub is never actually used or not; different data may result in different paths through the module's code, so the sub may be called when $x = 1.0 but not when $x = 1.5.

The bit about "subs that contain very similar code" is likely impossible to do programmatically. First, it's non-trivial to define "similar" code: functionally identical code may look quite different, and compile to something quite different. Secondly, there may be very sensible reasons why sub move and sub draw differ only in that one sets variable $pencolor = 0; and the other sets $pencolor = -1; (once, long ago, I wrote a FORTRAN-77 library to emulate the Tektronix PLOT-10 package; it had quite few subroutines that differed in just that way).

My suggestion for the "subs that contain similar code" is to print the (named) subs individually, get a bunch of highlighters, and apply judgement.

emc

Outside of a dog, a book is man's best friend. Inside of a dog it's too dark to read.

Groucho Marx

Comment on Re: Perl Analyzer?

Replies are listed 'Best First'.
Re^2: Perl Analyzer? by Anonymous Monk on Aug 04, 2006 at 21:54 UTC
I suspect that autoloader would make it difficult to determine whether a used module's sub is never actually used or not; different data may result in different paths through the module's code, so the sub may be called when $x = 1.0 but not when $x = 1.5. A sub may exist or not depending on how the code runs, too. Eval, autoload, symbol table changes, and code filters in @INC can all (re)define a subroutine as the code runs. Don't expect any sort of tool to catch that sort of thing; they can't. Don't expect perfection from these tools; they give a decent effort on code that's sufficiently conventional, but they can't do much with really exotic stuff.	[reply]
Re^2: Perl Analyzer? by Coldstone (Acolyte) on Aug 15, 2006 at 22:17 UTC
Those are exactly the kind of subroutines that would be nice to find and refactor so that $pencolor is passed in rather than hardcoded. Paper and highlighter? I asked the question because I don't want to waste time doing that. I feel that 'copy and paste' sytle code leads to code bloat and very, very fragile code.	[reply]
Re^3: Perl Analyzer? by swampyankee (Parson) on Aug 17, 2006 at 03:27 UTC
Ideally, you're right: code like that should be refactored unless there's a good reason not to do so (like a requirement to maintain subroutine interfaces, as it was in the `pencolor` case I mentioned. The code was actually in Fortran-66, and I detest `ENTRY` statements). It would, however, be quite difficult to have a program determine that two subs are doing the same thing, using different code, like one calculating factorials recursively and another doing so with a loop. emc Experience is a hard teacher because she gives the test first, the lesson afterwards. Vernon Sanders Law	[reply]
Re^4: Perl Analyzer? by adrianh (Chancellor) on Aug 17, 2006 at 07:06 UTC
It would, however, be quite difficult to have a program determine that two subs are doing the same thing, using different code, like one calculating factorials recursively and another doing so with a loop. So difficult as to be impossible in the general case - since it reduces to the halting problem.	[reply]