Be very careful doing this and make sure you're really sure what exactly is "unused" (via something like Devel::Cover or the like (as was mentioned above) and ample tests). Due to the dynamic nature of perl it's entirely plausible to have "unreachable" code that still could be called in that one corner case that you didn't test (e.g. that one strange routine that gets chosen from a dispatch table only every fourth blue moon during months not containing an R when run by a user named rufus).

(And make sure you're using good source control practices so you can back out to the last working version when you remove too much. :)

A particularly cleaver programmer can use PPI to map the code layout and GraphViz to create a image linking the code together.

Note: In this instance, I am not the clever programmer. A co-worker of mine did this for a C++ application and was able to delete 75% of the code the had in production (about 300,000 lines).

However, this is something you do need to be careful about otherwise you will be cursing yourself whenever something bad happens.

Consider:

use strict;
use warnings;

my $obj = bless {};
my @mem = qw(hello world);

for (@mem) {
    my $mem = "_do_$_";

    next unless $obj->can ($mem);
    $obj->$mem ();
}


sub _do_hello {print 'hello ';}

sub _do_world {print "world\n";}

sub _do_nothing {print 'nothing ';}
[download]

How could a mechanical parser decide what to keep and what to clean? How about when the contents of @mem depends on a preceding parse step and thus on user input?

It may be that tools such as UML::Class::Simple will help. Becoming familiar with a too-big codebase? and Analyzing large Perl code base. have good answers that may help too.

Not exactly related to the OP, but I am wondering: how does that code pass strict? Isn't it effectively using symbolic references, ie. generating a method name from a string?

I've trawled through much of the Perl documentation looking for something that addresses exactly that issue and can't find anything. Pretty much all of the pertinent examples use scalar variables rather than member functions.

It is however a very useful technique to dispatch to members in the context of a parser. Decorate the verb to avoid the possibility of nefarious calling of unintended members (DESTROY in the document being parsed could otherwise be a little unfortunate) and you've got a very easily extensible interpreter for all sorts of stuff (see sub describeAtom in Updated QuickTime format movie file dumper for example).

It's probably better to use the function reference returned from can (see 'UNIVERSAL: The Root of All Objects' in perltoot) though (amazing what you learn by re-reading the docs;) ):

for (@mem) {
    next unless my $member = $obj->can ("_do_$_");
    $obj->$member ();
}
[download]

---

DWIM is Perl's answer to Gödel