Re: How to look for unused methods/functions and variables/constants.
| From: | Nathan Nobbe | Date: | Fri, 14 Dec 2007 19:09:53 +0000 |
| Subject: | Re: How to look for unused methods/functions and variables/constants. | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-265903@lists.php.net to get a copy of this message | ||
On Dec 12, 2007 4:21 AM, Mathijs van Veluw <mathijs.van.veluw@smscity.com>
wrote:
> Hello there,
>
> We have a large project with lots of classes.
> Now i am wondering if there is a way to let something check all those
> files and tell me which methods/functions variables/constants etc..
> arn't used anymore.
>
> Or even which files arn't used anymore.
>
> Is there already something like this?
if you want to do it right, youll have to make use of the php tokenizer.
http://us.php.net/manual/en/ref.tokenizer.php
using this tool you can analyze the source to create a list of things like
- all classes defined in the code
- all functions defined in the code
once you have these lists you simply iterate over each member of them.
if there are no references to a specific function or class, it *should* be
safe
to assume it is no longer in use, however it could be new code, not yet in
use.
you can employ a similar technique for files using bash and some standard
unix programs. basically just build a list of all the files in your
source. then
iterate over the list, grepping the source. if there are no include /
require
directives for a given file it becomes a candidate for removal.
this still is not perfect however. there could be plenty of situations
where
legacy code is being referenced, but the execution path on a daily runtime
basis never takes that path. this can be a horrible thing, because new
developers who dont know the ins-and-outs of a massive code base will
stumble into this dead code in troubleshooting efforts only to be told by
somebody whos been there for a while that that code isnt the problem. and
then it is still left there anyway... (forgive me, ive had some undue
headaches
for these very reasons). i think the best practice in this case is to mark
said
dead code as a candidate for removal on the next release cycle of the
software.
using these techniques in concert i think you can keep the code fairly
clean.
-nathan