3

in short: I need to get a list of methods of our database API which are actually called and used within our code base.

longer: We have a quite big code base which is based on a (ugly) database API. The latter has a lot of interfaces and quite a big set of functionality which we don't need at all and we want to get rid of it. A first prototype of the rewrite should be one hundred compatible with the existing API code -- therefore should implement it's interfaces to make it easy having it built against our production code.

To define the subset of methods we use I could do some coverage analysis with dotCover or something else and run our unit tests but I'm quite sure that this would only yield a 80 to 90 percent success rate. What I need is more like a static analysis of our code. Another approach could be a dynamic wrapper for the api which logs every method call to have a decent coverage analysis after some usage.

I was curious if such an analysis could be done with a tool or if I should wrap the API to get the required informations (manually/automatically? It's really big, some hundreds or thousand methods).

Just to mention it: I have complete access to all sources, but they're distribution among a lot of modules with their own solutions.

Matten
  • 17,365
  • 2
  • 42
  • 64
  • Not sure if it's a 100% duplicate. However you might review http://stackoverflow.com/questions/245963/find-unused-code The short of it is to get Resharper. – NotMe Oct 01 '12 at 15:27
  • It's the 100% opposite, I think :) ReSharper does not help me (apart from clicking "find usages" on each and every method) – Matten Oct 01 '12 at 15:29
  • Okay, I'm not familiar with Resharper (don't like it myself). Another option is NDepend ( http://www.ndepend.com/ ) – NotMe Oct 01 '12 at 15:50

2 Answers2

2

As precised by Chris, NDepend can provide you with a list of API methods/fields/types called. Disclaimer: I am one of the developers of the tool.

A picture being worth a thousand words, the NDepend dependency structure matrix screenshot below, shows that in the NUnit code base, only the assemblies nunit.uiexcepion (row/column #6) and nunit.core.interfaces (row/column #18) are using the method List<T>.ToArray().

What we call third-party code (what you call API called), is shown in blue font. Only API methods/fields/types really used is shown. For example in the screenshot, the class HashSet<T> is not shown because it is not used by the NUNit code base.

All features of NDepend takes account of third-party code, but I expose here the dependency structure matrix because it is certainly the most suited feature to get a list of called methods within an API. A 14 days full-featured trial of the tool is available for download.

NDepend dependency structure matrix

Let's note that NDepend can also show what third-party code is not used anymore, or was not used and is now used, when you compare 2 different snapshots of your code base. In the screenshot below, we can see third-party methods used by NUnit v2.5.8 that were not used by NUnit v2.5.3.

NDepend search methods by change

Patrick from NDepend team
  • 13,237
  • 6
  • 61
  • 92
  • Exactly what I needed, thanks you for the quick introduction. We even had a license for NDepend :) Is there an option to export the matrix as .pdf or to print it? It's a long list and the .png export doesn't help much. – Matten Oct 02 '12 at 07:00
  • By now, the matrix can only be imported to PNG. But you can still write a code query like *from m in ThirdParty.Methods select new { m, m.MethodsCallingMe }* to get different export (txt, xml, xls, html) from the code query result panel. – Patrick from NDepend team Oct 02 '12 at 07:28
1

I'd take a look at any one of the various IL-weaver implementations used to create an Aspect-Oriented-Programming (AOP) layer on top of .NET - PostSharp is one that readily jumps to mind:

http://www.sharpcrafters.com/solutions/logging#

If I were you, I'd create a single "logger-like" aspect, then weave that aspect into all of the methods you want to catalog usage of. Then, run it through it's paces for a while. You should be able to collect a good set of usage data this way, which should help decide what you can get rid of safely.

One benefit this approach has over any number of static analysis tools is that it also catches any "dynamic" or meta-invocation of methods - not just compile-time bound invocations.

JerKimball
  • 16,584
  • 3
  • 43
  • 55