Discover NDepend
The problem of connectedness in the architecture of applications has recently received a lot of publicity, and has generated a large number of DI-nature frameworks and applications for static analysis and “smart refactoring”. I want to tell about one such application called NDepend.
What is NDepend ? This application is for static code analysis. It would seem that we already have an FxCop with our own set of rules, there is a ReSharper that can clean our code and refactor it well, there are also metrics in Team Edition , so why another analyzer?
NDepend is a program with a very large bias towards architecture, in particular towards revealing different errors in terms of strong connectivity between components, too open class visibility (non-optimal encapsulation), poor naming of structures. Also, NDepend gives a lot of complex metrics (for example, an indicator of abstractness) that can be analyzed and visualized.
')
Before I start working with NDepend (the trial version can be downloaded here ), I want to note that unlike, say, ReSharper, which can be bought even for a junior ( especially for a junior) and to get an increase in efficiency, NDepend requires a lot of knowledge from the user architecture, and he has a very specific terminology, and it must be studied .
To begin with, we will look at the most “colorful” features of NDepend, namely the possibilities of visualization. NDepend, like other static analyzers, loads your compiled code (it analyzes IL), including all dependencies. After analysis, it forms several artifacts.
Dependency graph (dependency graph)
The dependency graph illustrates the relationship between the elements of the analyzed code. Unlike programs that show dependencies between projects , NDepend can show any form of dependency, from assemblies, to specific methods.
The dependency graph synchronizes with the dependency matrix (shown below). Also, its elements are clickable, and allow right-click to manipulate the visualization of elements, produce queries, and so on. More on this later.
Dependency Matrix (dependency matrix)
The dependency matrix is ​​a two-dimensional grid that shows the total number of dependencies between components. When you click on a square, the dependency graph is updated, showing exactly the interactions you just clicked on. Attention: some components with a high degree of connectivity may not be drawn immediately (since there are many of them). Here's an example of a fragment of the illustrated interaction between
The matrix of dependencies allows for drill-down, that is, to delve into the structure of the program in order to understand exactly where the relatedness is. To do this, you can use the plus sign at the beginning of the columns and rows. For example, in the screenshot below, I expanded the NHibernate namespace, and I can see the interaction down to the individual methods.
Metrics
The Metric Visualizer allows you to visually evaluate your code base. In particular, you can compare the elements of your code by the amount of IL instructions, the number of methods, and many more criteria. The diagram itself is naturally clickable.
This window, though called "metrics", but actually those metrics that appear in the drop-down menu are the same metrics about which the report is presented. I will not write about the report separately, I will just say that a large number of unusual terminology appears there. In order to quickly understand what is, for example, afferent coupling, I recommend this poster , where everything is described quite well.
Other windows
Information window shows additional information on the selected item. For example, if you selected a dependency between components, this window will tell you how many dependencies are found, and what type.
The class browser works just like in Studio. After selecting an item from the tree, metrics indicators for the selected item will be displayed in the information window. Also, the element can be manipulated by the context menu, which we will talk about separately.
Yes, and one more feature (and, accordingly, another window) is a search by codebase.
For static code analysis, NDepend uses a SQL-like language to conduct queries against a code base. This language is called CQL (Code Query Language). This language actually contains those constructions that are useful for analyzing exactly the code. On the basis of CQL, NDepend contains a considerable number of “recommendations.” For example, what an offer to do all immutable structures looks like:
I deliberately left a comment to show that all the recommendations with which NDepend is supplied are commented, and you can read about them.
The static analysis panel shows the tree of those rules that were checked.
The CQL panel respectively shows the results of the query, i.e. those code elements that it makes sense to refactor.
Driving NDepend locally on your own car is good, but not cheap. Therefore, there is another possibility - namely, to integrate NDepend into the process of continuous integration, because NDepend comes with tasks for MSBuild. An example of how to integrate NDepend and TeamCity is described here , but if you google it, I am sure that you can find other tutorials, for example, for CC.Net or for using NAnt.
If you are interested in this program, I recommend downloading the trial version and driving this tool through your code. Who knows - maybe it will become an integral part of your programming practice. Good luck!
What is NDepend ? This application is for static code analysis. It would seem that we already have an FxCop with our own set of rules, there is a ReSharper that can clean our code and refactor it well, there are also metrics in Team Edition , so why another analyzer?
NDepend is a program with a very large bias towards architecture, in particular towards revealing different errors in terms of strong connectivity between components, too open class visibility (non-optimal encapsulation), poor naming of structures. Also, NDepend gives a lot of complex metrics (for example, an indicator of abstractness) that can be analyzed and visualized.
')
Before I start working with NDepend (the trial version can be downloaded here ), I want to note that unlike, say, ReSharper, which can be bought even for a junior ( especially for a junior) and to get an increase in efficiency, NDepend requires a lot of knowledge from the user architecture, and he has a very specific terminology, and it must be studied .
To begin with, we will look at the most “colorful” features of NDepend, namely the possibilities of visualization. NDepend, like other static analyzers, loads your compiled code (it analyzes IL), including all dependencies. After analysis, it forms several artifacts.
Dependency graph (dependency graph)
The dependency graph illustrates the relationship between the elements of the analyzed code. Unlike programs that show dependencies between projects , NDepend can show any form of dependency, from assemblies, to specific methods.
The dependency graph synchronizes with the dependency matrix (shown below). Also, its elements are clickable, and allow right-click to manipulate the visualization of elements, produce queries, and so on. More on this later.
Dependency Matrix (dependency matrix)
The dependency matrix is ​​a two-dimensional grid that shows the total number of dependencies between components. When you click on a square, the dependency graph is updated, showing exactly the interactions you just clicked on. Attention: some components with a high degree of connectivity may not be drawn immediately (since there are many of them). Here's an example of a fragment of the illustrated interaction between
NHibernate and Iesi.Collections :The matrix of dependencies allows for drill-down, that is, to delve into the structure of the program in order to understand exactly where the relatedness is. To do this, you can use the plus sign at the beginning of the columns and rows. For example, in the screenshot below, I expanded the NHibernate namespace, and I can see the interaction down to the individual methods.
Metrics
The Metric Visualizer allows you to visually evaluate your code base. In particular, you can compare the elements of your code by the amount of IL instructions, the number of methods, and many more criteria. The diagram itself is naturally clickable.
This window, though called "metrics", but actually those metrics that appear in the drop-down menu are the same metrics about which the report is presented. I will not write about the report separately, I will just say that a large number of unusual terminology appears there. In order to quickly understand what is, for example, afferent coupling, I recommend this poster , where everything is described quite well.
Other windows
Information window shows additional information on the selected item. For example, if you selected a dependency between components, this window will tell you how many dependencies are found, and what type.
The class browser works just like in Studio. After selecting an item from the tree, metrics indicators for the selected item will be displayed in the information window. Also, the element can be manipulated by the context menu, which we will talk about separately.
Yes, and one more feature (and, accordingly, another window) is a search by codebase.
For static code analysis, NDepend uses a SQL-like language to conduct queries against a code base. This language is called CQL (Code Query Language). This language actually contains those constructions that are useful for analyzing exactly the code. On the basis of CQL, NDepend contains a considerable number of “recommendations.” For example, what an offer to do all immutable structures looks like:
// <Name>Structures should be immutable</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE IsStructure AND !IsImmutable AND !IsInFrameworkAssembly<br/>
// It is deemed as a good practice to make your structure immutable.
// An object is immutable if its state doesn't change once the object has been created.
// Consequently, a structure is immutable if its instances are immutable.
// Immutable types naturally simplify code by limiting side-effects.
// See some explanations on immutability and how NDepend supports it here:
// http://codebetter.com/blogs/patricksmacchia/archive/2008/01/13/immutable-types-understand-them-and-use-them.aspx
I deliberately left a comment to show that all the recommendations with which NDepend is supplied are commented, and you can read about them.
The static analysis panel shows the tree of those rules that were checked.
The CQL panel respectively shows the results of the query, i.e. those code elements that it makes sense to refactor.
Driving NDepend locally on your own car is good, but not cheap. Therefore, there is another possibility - namely, to integrate NDepend into the process of continuous integration, because NDepend comes with tasks for MSBuild. An example of how to integrate NDepend and TeamCity is described here , but if you google it, I am sure that you can find other tutorials, for example, for CC.Net or for using NAnt.
If you are interested in this program, I recommend downloading the trial version and driving this tool through your code. Who knows - maybe it will become an integral part of your programming practice. Good luck!
Source: https://habr.com/ru/post/70387/
All Articles