Search Wiki:

Future Focus: Call Hierarchy

By DJ Park and Charlie Calvert

Welcome to the second Future Focus post. Last month we looked at a C# language feature called Dynamic Lookup. To help maintain a balance, this month we intend to investigate a new IDE feature named Call Hierarchy. This feature is language agnostic, so we welcome input from both C# and VB developers.

Please enter your feedback here.

It is important that readers of this post have the right expectations. The information you find in this text is meant to be a helpful guideline for C# developers, and not a binding commitment. We are not attempting to give a complete list of features in the product, but only to share what we can in a way that will be easily accessible to all C# developers. The Visual Studio schedule, unforeseen technical problems, intellectual property rights and competitive pressures may impact our schedule or our ability to share our plans. We will, however, do our best to keep you up to date on the latest news from the team as they design and implement future versions of the C# language and IDE.

Future focus is not designed to present a detailed specification of future features. Instead, its purpose is to outline in broad strokes, and easy to understand terms, the directions the team will take in the future. I will report back to you on the impact of your comments, but please be patient, as it can take a long time for the team to make a final decision.

What is a Call Hierarchy?

The Call Hierarchy is one of many features that the team has planned for the next version of the IDE. It allows developers to explore a code execution path by showing all calls to, or calls from, a selected method.

There are several scenarios in which this functionality might be useful. It will allow developers to:

  • Get a better understanding of how code flows
  • Navigate through their code
  • Understand the impact of making changes to their code.

The Call Hierarchy differs from existing features in the following ways

  • Unlike Find All References, it will allow you to drill down several levels deep so that you can view complex chains of method calls and additional entry points.
  • Unlike the run time Call Stack displayed by the debugger which shows a single code execution path, the Call Hierarchy will be available at design time, and it will allow you to explore all possible execution paths.

Walk Through

It is important to remember that the Call Hierarchy is still under development. All the ideas, terms and screenshots are not only subject to change, but likely to change. We are showing you a very early version of our plans precisely because it now, at this nascent stage of development, when your feedback is most useful and most likely to bear fruit.

To begin our exploration of the Call Hierarchy, let’s posit a simple class with four methods as shown in Listing 1.

Listing 1: This simple program has four interrelated methods that can be easily shown in a call hierarchy.

CallHierarchyFocus00.jpg

We will show two ways of visualizing the call hierarchy for the methods shown in Listing 1.
  • The “In-Depth Understanding” visualization will allow developers to thoroughly explore a call hierarchy.
  • The “Quick Understanding” visualization will help developers quickly navigate or explore a call hierarchy while still inside the editor window.
Our current plan is to have both types of visualizations in the shipping product. The user will be able to select the visualization they prefer by the way they invoke the feature.

Imagine that your current focus is on the highlighted call to Method2(). In order to better understand the code execution paths associated with this method, you could do one of the following:
  1. In-Depth Understanding: Right-click on Method2() and select the “View Call Hierarchy” from the popup menu shown in Figure 1. This will launch the “Find Symbol Results” dialog shown in Figure 2. It will also be possible to reach this dialog from the Class View or the Object Browser.
  2. Quick Understanding: Place your cursor on Method2() and invoke a keyboard shortcut or select an option from the context menu. You will see the inline view of the Call Hierarchy visible in Figure 3.

The “In-Depth View” of the Call Hierarchy

We will begin our exploration of this feature by explaining Option A, designed to give you an In-Depth Understanding of your code.

CallHierarchyFocus01.jpg

Figure 1: If you right click on a method in your code, in the Class View, or in the Object Browser, a popup menu will appear with an option to View the Call Hierarchy.


CallHierarchyFocus02.jpg
Figure 2: This mock up of the Call Hierarchy feature has not been finalized, but it should provide enough detail to allow you to send us feedback.

The Call Hierarchy results window shown in Figure 2 consists of several panes that can be toggled to allow the user to maximize window space when needed. Here is a breakdown of what you see in that dialog:
  • The Calls To tree view shows all the methods that call the selected method. The tree visible in this sub-window can be expanded so that you can drill deeper into the stack of callers.
  • The Calls From tree view shows all the methods called by the selected method. This tree can be expanded to further explore the stack of called methods.
  • Preview – This pane provides a quick read-only preview of the code surrounding the selected method.

A developer can interact with this window in the following ways:
  • A single click in the Calls To or Calls From panes would update the Preview pane to bring into view and highlight the selected method.
  • Double clicking a method name would take you to the declaration of the selected method in the editor.
  • Right clicking on a method name would bring up a context menu with an option to reset the root of the Call Hierarchy.
  • Selecting a method in the History drop down list would reset the root of the Call Hierarchy to the selected method.

The “Quick Understanding” View of the Code Hierarchy

We are now going to explore Option B, which is invoked when a user selects a hotkey or selects the option through the context menu. Rather than popping up the Call Hierarchy dialog shown in Figure 2, the user will instead invoke the inline view of the Call Hierarchy shown in Figure 3.
CallHierarchyFocus03.jpg
Figure 3: The inline view of the Call Hierarchy is designed to allow the user to quickly explore or navigate through multiple call stacks.

The visualization of the Call Hierarchy shown in Figure 3 allows developers to get a quick understanding of a particular method without losing their context. This view is modeled after the Debugger datatips feature and allows the user to drill deep into the Calls To and Calls From stacks associated with a particular method. You can, for instance, select the plus symbol before the node labeled Program.Method1() in order to see that MyMethod() calls Method1().

Feedback Guidance

Our experience with the first Future Focus post has taught us that the community has many well thought out ideas and can provide us with excellent feedback of the highest possible quality. We are looking forward to hearing your opinions on the Call Hierarchy.

The IDE team has many plans for the next release of Visual Studio. We wish we could share them all with you, and ask you to rate their relative importance. Unfortunately, that is not possible. At this time, we are only looking for your feedback on this particular feature.

Please read the guidelines below, and try to craft your feedback so that we can make the best use of your suggestions:
  1. Please enter your feedback here. Please do not start a new discussion thread on this topic.
  2. Please keep your feedback focused on the Call Hierarchy. We want to know if think you will find this feature useful, if you like the implementation shown here, or if you envision a different implementation.
  3. There are many different ways to implement the Call Hierarchy. If you have alternative design proposals for its user interface, please let us know.
    1. Should we have two separate visualizations as outlined in the previous section, or should we select one of these options, or some third alternative?
  4. The Call Hierarchy is related to several other features that help you understand your code, including Find all References, Class View and the Object Browser.
    1. Should this feature replace Find All References, expand upon it, or live side by side with it?
    2. How would you like to see us integrate the Call Hierarchy into the Call View, Object Browser, or other parts of the IDE.
  5. Do you like the Call Hiearchy Results window shown in Figure 2? Can you think of ways to improve it?
We love having this opportunity to share our plans with you. We look forward to hearing more of the same excellent and thoughtful feedback that we got from you when asking about Dynamic Lookup.

Please enter your feedback here.

DJ Park is a Program manager on the C# IDE team and focuses on feature design and performance.

Charlie Calvert is the C# Community PM.
Last edited Mar 6 2008 at 11:26 PM  by CharlieCalvert, version 8
Comments
iinlane wrote  Mar 26 2008 at 8:46 PM  
Along with call hierarchy I would really like to see what (unhandled) exceptions the calls may throw. There could be a small (green or red) icon after method name, clicking of which would pop a list of handled (in green) and unhandled (red) exceptions.
Robert.

eschneider wrote  Apr 1 2008 at 5:45 PM  
Would like to see a Visual flowchart and be able to click on a item and goto the code file.

TechVsLife wrote  Apr 16 2008 at 9:54 AM  
Would like to be able to add this to comments section of each procedure, to have it print out with print out of procedures. This would have to update on changes, say after each compile/rebuild. Could have something like Word's old form fields to indicate dynamic update comment. Dynamic comments would be of more use than just creating "calls"/"called by" comments.
Would be useful in any case to be able to PRINT a map of the calls/called by relationships.
btw, also would be good to allow chapters/sections of the chm help file to be printed (instead of creating 1,001 print jobs, one per page).

Colin wrote  Apr 23 2008 at 3:39 AM  
Could this be extended so as to provide an override to the default VS IDE exception handler?
For example, when placing custom controls onto a design surface the initial beta versions of these controls causes the ide some grief ... however at best you get an "object not initialised" message (at worst you get an ide restart). Is/would it be possible to override the default exception handler to a custo one which provides a stack trace etc?
Even with the best try/catch blocks you still have cases (eg changing a collection, returning a null property into the property grid) which is raised within the IDE itself (and outside of your custom control, but cause by the actions of the custom control).

HansGuckInDieLuft wrote  Jun 12 2008 at 12:31 PM  
I second iinlane's suggestion: I'd like to have more emphasis on code analysis, e.g. How many times a class or a method is being called, and from where, are there orphans etc.

ml2008 wrote  Jun 23 2008 at 3:27 PM  
I too am a visual person and think a flow chart would be nice. Also when you mouse over a calling method in figure 3 the comment's would appear like the intellisense feature.

dvanderboom wrote  Aug 21 2008 at 4:57 PM  
Have no idea why you'd want to print out your code TechVsLife :), but the dynamic field idea for XML comments isn't a bad idea, especially when linked to parameter names and types, so as not to have to update the comments manually when the method signature is changed.

Overall, this is Call Hierarchy is a needed tool, but what about using the Reflector Add-In, which already has Analyze? Analyze is a powerful feature, since it not only gives you a call hierarchy, but other needed tools as well, such as Depends On, Used By, Exposed By, Initialiized By, etc. Of course, Reflector uses reflection on compiled assemblies, and I'm guessing you're going after the same type of analysis against potentially uncompiled code (which is good). But by all means, steal some of the good ideas already in Reflector.

Another aspect of this same idea would be an enhanced search. Instead of searching for text, search for all code that instantiates this variable, references this method or class, and other semantically-aware code queries...

dvanderboom wrote  Aug 21 2008 at 5:04 PM  
Also, the Quick Understanding UI mockup looks very nice, but some kind of scrolling container will be necessary since these lists will occassionally get VERY long. As per my previous post, if more is offered than just calls and called by, it would be nice to have which sections appear be configurable by the user.

Along the same configurability lines, Intellisense would be better off with a little toolbar at the top of its result list, so that I could toggle whether extension methods appear in the list (which clutters the list and makes it harder to find members that actually belong to the type), be able to sort the list differently (by name, by member type, or by return type), and to toggle whether to view base class members or not.

MaximS wrote  Aug 26 2008 at 11:54 PM  
Very useful feature, both the "in-depth" and "quick" views. Renaming "Calls To" to "Calls" and "Calls From" to "Called From" would reduce confusion.

modeeb wrote  Sep 5 2008 at 10:14 AM  
Last week, I had to generate the class diagram, print it, add call paths to the diagram manually in order to get understanding of a complex structure
I guess this feature will be much handy
Also, why not think of a sequence diagram generator based on this feature

ShannonBarber wrote  Nov 24 2008 at 6:24 AM  
If it has not been done already, a competitive analysis of Understand C/C++ would be the place to start and winding up to Polyspace if dynamic analysis is a business goal.
These in turn are only effective once combined with a comprehensive refactoring tools, e.g. ReSharper.

As such this feature is uninteresting - it is but a drop in a bucket of water of the feature list for static & dynamic analysis tools.
Reintroduction of integrated profiling and profile-guided optimization would be nice (features you lose going from C++ to C#).
Integration of a static-analysis & refactoring tool would be nice.
Discussion about a solitary feature is a distraction.

SmallStoneCow wrote  Apr 29 2009 at 5:46 PM  
Sounds great - Make sure it cuts and pastes well for documentation - and output as a Sequence Diagram Fragment (which is basically what this is) would also be nice.

Updating...
Page view tracker