In my post about the new
Interactive Code Dependencies Graph
feature of NDepend,
I explained how to use the Indirect Mode of the Dependency Matrix to obtain
some Graph of path from 2 code
elements, from A to B. I also explain how to obtain some Graph of a cycle involving 2 code elements. By
code element, I mean assembly, namespace, type, method or fields and the 2 code elements
are not necessarily of the same kind. You can be interested in getting a path from a method to a type for example.
following Dependency Matrix in Indirect Mode tells that the assembly System.Data is indirectly using the assembly System.Drawing with a minimal depth of 4. By clicking the cell you
instantly get a path of depth 4 shown in the Graph panel on the right.
In the comment of the Interactive
Code Dependencies Graph post, Sidar
Can I see all the paths in path
graph instead of shortest one?If I can, it will be a really useful thing to
identify and reduce YAGNI s.
And indeed yes you can thanks
to the flexibility of Code Query Language (CQL).
With CQL you can readily enumerate all assemblies (directly or indirectly) used
by System.Data AND that are (directly
or indirectly) using System.Drawing.
For this, you just have to write the following query:
Interestingly enough, the
Query Result panel automatically
displays the values for the 2 metrics DepthOfIsUsedBy
“System.Data” and DepthOfIsUsing “System.Drawing”.
NDepend automatically infers all
metrics involved in a CQL Query. Notice also the ASSEMBLY prefix used in code element name to avoid confusion with
the 2 namespaces also named System.Data and System.Drawing.
Logically, all paths from
System.Data to System.Drawing involve only these 14 assemblies. To get all paths from
System.Data to System.Drawing you then just need to export these 14 assemblies to
a Graph by clicking the Export to Graph
button in the Query Result panel (right click the row 14 assemblies matched). Et voila:
The funny part is that until Sidar asked if it was possible, I admit that we never thought about the possibility of All Paths from A to B. It is accidentally possible, as many things we didn’t forecast, thanks to the flexibility of NDepend. The same story happened in the past when Jim Bolla explained how to use NDepend to write CQL rules to check for Separation of Concern but also for many CQL queries like when Gaël Covain is using some CQL regular expression to match methods and types with lengthy names (btw these queries have been since added in the list of default CQL rules under the Naming Convention group).