views:

339

answers:

7

I have a project with very messy code - lots of duplication and dead code here and there.

Some time ago there was zero code coverage by unit-tests but now we're trying to write all new code in T.D.D. manner and lowering technical debt by covering "old" code by unit-tests as well(test-last technique).

Business logic's complexity is quite high and sometimes no one can answer whether some methods are used or not.

How this dead code methods can be found? Extensive logging? Higher test coverage?(It is not very easy because customers want new features to come out)

+3  A: 

xdebug's code coverage tools allow you to test which lines of code are actually being executed, without needing to put trace statements in all of the functions/methods.

Ben James
Ben, can I use it for code which is not covered by unit-tests?
Fedyashev Nikita
The 'code coverage' in the xdebug sense does not mean test coverage. The two are not related, so you can use this to see which lines are executed, whether or not they are tested.
Ben James
You can get data on code coverage during tests simply by enabling the code coverage data collection right before you run all your tests, and turn it off right after.
Ether
+1  A: 

I don't know of a way to detect code that is completely unused, that may be beyond the abilities of all the tools out there. But in terms of the tools out there, hit http://phpqatools.org/ for a good rundown of them.

  • So far, one of my favorites in phploc which tears apart your code from an Object Oriented perspective and gives you details on how many classes vs how many functions vs how many tests vs average loc per function vs Cyclomatic Complexity.

  • My next favorite is phpcpd which is the "PHP Copy-Paste Detector". It tokenizes your entire codebase, looks for common signatures, and gives you a list of files with line numbers.

  • There are lots of other tools on that page, choose the ones that are useful to you.

We're actively using these tools in web2project and in the two years since we forked from dotProject, we've dropped about 35% of the codebase from refactoring, eliminating duplication (originally 12%, now about 2.5%), and generally structuring things better. And that's counting our 15k+ lines of Unit Tests. :)

CaseySoftware
+2  A: 

I would recommend running through the system with xdebug profiler (http://xdebug.org/docs/profiler).

Run through the system the view the logs with http://code.google.com/p/webgrind/ and physically see what's being called.

Shane
+1  A: 

Regarding profiling tools, if you decide to go that way you may take a look at xhprof http://developers.facebook.com/xhprof/
It has smaller size of the output files and web interface that you could embed into your app for continuous tracking. It is able to generate visual representation of call tree. I recommend it over xdebug for that purpose.

ivanjovanovic
A: 

I believe that someone has implemented a flavor of Structure101g that uses xdebug data - s101 will then detect any unused clusters, i.e. files that use each other but are disconnected from the main codebase.

Chris Chedgey
+1  A: 

See the SD PHP Test Coverage Tool. You exercise your code any way you like, including (or not) running test suites any way you like. At the end of execution, you can see a display of what code was executed (there are screenshots at the website). Code that is not executed may be dead, and requires some more analysis on your part, but if you exercise the system well, unexecuted code is either error handlers or really dead stuff. The PHP Test Coverage tool does not require any changes to your PHP server.

The SD CloneDR tool finds duplicate code across very large source code bases. It is language sensitive (covering C, C++, Java, C#, Ada, Fortran as well as PHP4 and PHP5) so it isn't fooled by changes in formatting, whitespace or the presence or absence of comments. It will detect exact copy clones, and near miss clones. The website shows example clone reports for several languages.

Ira Baxter
+1  A: 

It's a little late now, but PHPDCD claims to do this statically, which should give you a much more informative result than having to profile actual code execution with xprof / xdebug.

El Yobo