I'm in a situation where I'm required to make at least some effort to remove never-used code from my source code. The general preference is to use a static code analysis tool. We've had great luck with this in other projects, but the folks I hear from are mostly C/C++ developers working on device level code.
I'm a web developer working on a Java EE system. The favored tool for analysis is Coverity Prevent, although I could probably advocate for something else if I could make a strong case that it was more appropriate to the technology we're developing with.
I find myself dubious -- what the effectivity of static code analysis for dead code, when you are running against a system with a lot of abstractions? For example, we use Spring's dependency injection, as well as JSF. In both cases, there's no easy way to trace through the function calls from front end to back end and make a complete picture of what gets called and what doesn't.
I'm very concerned that the false positives on a dead code check will outweigh the value of running the tool in the first place.
What is the experience with this scenario? Did you manage to get value from a static code analysis tool when your architecture used a lot of abstractions? Was there anything you had to do to get it to work with a minimum of false positives?
I previously worked at Coverity, on the Java static analysis product.
This particular task of finding dead code can be hit-or-miss for a static analyzer. For dead methods in particular, meaning a method which cannot be called at runtime, the false positive rate will be very high without a lot of tuning from you to inform the static analyzer about all the dynamic entry points.
For deadcode within a method, if your analyzer has that capability, the results should be pretty good, as the analysis will not make any assumptions about the input data. Even assuming all possibe inputs, it is possible to find dead code where correlated logic prevents certain branches from being taken.