NDepend analyzes .NET assemblies of an application and generates reports containing design quality metrics, warnings and diagrams. NDepend is a complement and not a competitor of FxCop, the main .NET static code analyzer provided by Microsoft. Very few needs are handled by both tools. Basically:
Compared to other .NET code metric and static code analyzers, here are the main differences:
The support for CQL (Code Query Language) is indeed the main enhancement to the tool. While creating CQL, I wanted a means to express all sorts of design intentions such as the following:
Often, after a couple of releases, primary designer intentions are lost and not respected anymore. As a means to avoid the rot of the design over time, CQL is a new weapon for agile programmers.
CQL is similar to SQL and supports the SELECT TOP FROM WHERE ORDER BY pattern. This resemblance is not by chance. NDepend considers your code and its underlying graph of dependencies as a database and CQL allows querying and checking some assertions on this database. Here are some CQL sample constraints:
I figured out that this approach is also a good means to write metrics thresholds or naming rules such as the following:
The complete CQL 1.0 specification is available here.
The second enhancement of NDepend 2.0 is the VisualNDepend.exe UI which allows developers to have a global understanding of their code thanks to an interactive treemap view. VisualNDepend provides also a CQL editor which supports intellisense and verbose compile error description. While editing CQL queries, matched code elements are immediately highlighted on the view. For example here is a screenshot which gives an idea about the set of methods of the .NET framework 2.0 which overcome the limit of 200 IL instructions (highlighted in blue).
[TABLE]
Numerous minor enhancements are also available. For example the NDepend.Project.exe tool allows editing NDepen
To continue reading for free, register below or login
To read more you must become a member of SearchWinDevelopment.com
d
projects instead of previous handcrafted XML configuration files. The report layout is now configurable. You can keep historics of NDepend reports.
In development, the main pitfall designers/developers should avoid is losing the control over the structure of their code. To do so, programmers must continuously wrestle to reduce the complexity of their code. This is one of the tenets of the agile programming manifesto (Continuous attention to technical excellence and good design enhances agility). Part of the complexity of a program is proportional to the sum of awkward potential dependencies which could be created in the code without yielding a warning or an error. In other words, encapsulation is a mean to reduce complexity. Encapsulation is traditionally achieved with OOP visibility levels such as public, internal/friend, protected, private. As we saw, CQL constraints constitute a complement to OOP visibility levels to express custom encapsulation needs. I consider them as some kind of regression tests on the design of an application.
Another pitfall is to avoid to regularly check the quality of the code with a tool. Numerous quality issues can be pinpointed by NDepend and most of them aren't handled by FxCop. CQL is a good way to provide your own metric thresholds for example to detect methods with too many IL instructions, too many parameters or too many local variables, types with low cohesion, high depth of inheritance or high footprint etc. However keep in mind that high metric values don't necessarily pinpoint a problem. For example it is legitimate that the System.String class has almost 200 methods and that the System.Windows.Forms.DataGridView has more than 1000 methods. They are necessary evils. Other code quality issues are also handled by NDepend such as warnings if the visibility of a type or a member is not optimal (i.e for example if in the context of the analyzed application a method could be declared protected instead of public) and warnings about type and members which are not statically used (i.e potential dead code).
