Visualizing Code Metrics with Treemap


In the Metric View, the code base is represented through a Treemap. Treemapping is a method for displaying tree-structured data by using nested rectangles. The tree structure used in NDepend treemap is the usual code hierarchy:
  • .NET assemblies contain namespaces
  • namespaces contain types
  • types contains methods and fields
Treemap rectangles represent code elements. The option level determines the kind of code element represented by unit rectangles. The option level can take the 5 values: assembly, namespace, type, method and field. The two screenshots below show the same code base displayed by type level on the left and namespace level on the right.

The option Code Metric of the treemap determines the size of rectangles. For example if level is set to type and metric is set to number of Lines of Code, each unit rectangle represents a type, and the size of a unit rectangle is proportional to the number of Lines of Code of the corresponding type.

If a CQLinq query is currently edited, the set of code elements matched by the query is shown on the treemap as a set of blue rectangles. In the screenshot below, a CQLinq query matches the 200 largest methods. Here the treemap level is method and the metric is number of lines of code. As expected, we can see that blue rectangles represent the 200 largest unit rectangles of the treemap.

The screenshot below also shows that the currently selected code element (here the assembly PaintDotNet) is shown as a red rectangles on the treemap.

▲▲ Go to Top ▲▲

Common Scenarios

By choosing an appropriate combination of metric and level values, the Metric View helps you see patterns that would be hard to spot by other means.

    Too Big, Too Complex

    NDepend provides many code metrics to spot too big and too complex code. Method with too many parameters, too many variables, too many lines of code, too high cyclomatic complexity etc... should be banished. The same way types with too many lines of code should be banished too.

    On the screenshot below, the treemap level is set to type and the metric is number of lines of code. Large rectangles represent large types of the code base. Hovering a rectangle with the mouse indicates the type metric values, here the type number of lines of code. Clearly, code treemapping helps not only spotting too large and too complex code elements, but also, it helps comparing their respective size and complexity.

    ▲▲ Go to Top ▲▲

    Flaws Localization

    In the screenshot below we are asking with a CQLinq query, for methods with too many parameters and too many variables. Blue rectangles show matched methods on the treemap. Here the interesting point is that some matched methods seem to be grouped. Because treemap is a hierarchical view, if a set of code elements is grouped, it means that the code elements belong to the same parent. And indeed, here the 5 methods grouped belong to the same namespace.

    Spotting the parent types of these 5 methods would have been hard without treemapping. Now the code quality reviewer can focus his attention on this region that seems to contain more flaws than other part of the code base.

    ▲▲ Go to Top ▲▲

    Code Coverage Density

    By using side-by-side the Search panel searching for code coverage ratio, and the Metric View, one can obtain some subtle information about how the code is covered by tests. In the screenshot below, we are asking through the Search panel, for types 100% covered by tests. The Search panel is actually a CQLinq query generator. For example, the CQLinq query below is generated to ask for types 100% covered by tests.
    from t in Application.Types 
    where t.PercentageCoverage >= 100 
    orderby t.PercentageCoverage descending, 
    select new { t, 
    t.NbLinesOfCode }
    The blue rectangles on the treemap show all types 100% covered by tests. By exploring this treemap, a wide range of information concerning code coverage can be inferred. For example, as expected the UI code is much less covered than framework code for example.

    ▲▲ Go to Top ▲▲

    Top-Down Code Exploration

    The NDepend treemap metric view supports zoom-in and zoom-out. This makes easy to zoom on a particular assembly, namespace or class. This can be especially useful to explore and compare the volume of components in terms of lines of code.

    By no means should productivity be measured in terms of lines of code. However counting lines of code has been proven to be a useful metric to accurately estimate software, given a certain context of an organization. The code base features are somehow partitioned into assemblies, namespaces and types. With treemapping, these artifacts become rectangles that sit side-by-side. Rectangles areas, hence features weight, can be compared visually. Being able to periodically explore code size through treemaping is a unique way to build an accurate sense of feature weight and feature cost.

    Do the experiment to visualize treemap on a code base you know well, and you'll be surprised to discover unexpected feature size.

    ▲▲ Go to Top ▲▲

    Code Structure Observations

    Choosing to use the Metric View with a metric different than volume (lines of code, number of parameters for methods...) or complexity, can reveal interesting observations.

    The ranking metric is a code metric that measure the popularity of a type or a method in a code base. Using treemapping with the ranking metric gives a clear view of where popular types are declared. This quickly gives information about what is important in the code base.

    The screenshot below shows types of the Paint.NET code base treemaped with the ranking metric. The treemap indicates that some types in PaintDotNet.Base are pretty popular concepts, and this is indeed the case.

    The same kind of interesting Code Structure Observations can be made with code metrics such as Afferent/Efferent coupling or Level.

    ▲▲ Go to Top ▲▲