Analysis of call graphs ranges from easy to ugly:

- Virtual calls (easy?): Do you show just the statically-known class or include all derived classes?

- Callbacks (easy? hard?): What's the ideal representation? Sequence diagrams? Something else?

- Functors/delegates/lambdas/etc: No idea how you'd analyze or represent these nicely.

How do you render the call graph? I wouldn't think that anything less than a Graphviz-style layout would be sufficient, but I've done call graphs with Graphviz, and real-world graphs tend to become completely unreadable very quickly. The density of calls is usually just too high to visualize cleanly.

What might be really badass is if you could trace data flow in the graph. For example, let's say we have a call from method A to method B, where one of the arguments is passed straight through without change. It might be nice to indicate that in the graph layout:

| Namespace | ========> | Namespace2 |
| Class     |           | Class      |
| Method    |           | Method     |
| Arg1      |     /---> | Arg1       |
| Arg2      | ---/

I like the tag-and-view idea. I was thinking that in C#, you could easily adapt the #region/#endregion directives to function as tagging constructs:

#region tags: spells, attacks
// ...whatever code you want to put here...
#endregion

You might want to automatically assign a GUID to each region as well, so that you could cherry-pick regions instead of being forced to get every region with a specific set of tags.

#region guid: {1BD2771D-D38F-4AB1-8076-8A10D5EBDE51} tags: spells, attacks
// ...whatever code you want to put here...
#endregion

Your view files would then just list guid and tag expressions:

guid: {1BD2771D-D38F-4AB1-8076-8A10D5EBDE51}
tags: spells && attacks

(In my example, that region matches the guid AND the tags, but this would obviously not be necessary)

[Tag("fireball","spells","attacks")]
[Tag("fireball, spells, attacks")]
[Tag("fireball"), Tag("spells"), Tag("attacks")]

Let them choose. If it's an interface, then you indicate as such (icons), if I know X is going to be a Q then I'll want to be able to select Q.F() instead of B.F(). I should be able to easily change my choice later though, in case I was wrong or need to trace the flow through two or more different sets of derived methods. If we're doing this in a "view" based format, you could have separate chunks of the view for each virtual method I'm tracking.

That's a good point. I typically think of call graphs as something the IDE generates which I can't tweak. If we let the user tweak the view to show what they're interested in, then it gets much better!

(side note: I found something I had been looking for which sounds a lot like this, but is currently debugging-oriented: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-bfef-83bd428a0acb )

That's another good point - I was only thinking of this from a source perspective. .Net definitely emphasizes including metadata in DLLs so that consumers don't NEED the source code to use it conveniently. Attributes might be a good way to do this (I don't know of any alternatives).

If you had to add those attributes to everything by hand though, it would be seriously tedious. Ideally you could somehow multi-select whatever you want to add tags to and have the IDE add the attributes for you.