NDepend

Home

Download

Product

Purchase

Documentation

Support

Home > Product > Features

Features

Code Query Language (CQL)
Compare Builds
82 code metrics
Manage Complexity and Dependencies
Detect Dependency Cycles
Harness Test Coverage Data
Enforce Immutability and Purity
Warnings about the health of your Build Process
Generate custom report from your Build Process
Diagrams
Facilities to cope with real-world environment

Code Query Language (CQL)

NDepend supports the Code Query Language (CQL) (specification available here) for maximum flexibility. Basically, NDepend considers your code as a database and you can write some CQL statements to query and check some assertions on this database. As a consequence, CQL is similar to SQL and supports the SELECT TOP FROM WHERE ORDER BY pattern. For example the following CQL query matches all public methods that have more than 30 lines of code:

SELECT METHODS WHERE NbLinesOfCode > 30 AND IsPublic

CQL will help you answer in seconds your questions about your code base:

Is the code layered correctly?
SELECT NAMESPACES WHERE !HasLevel
Which methods have been refactored since the last release and is not thoroughly covered by tests?
SELECT METHODS WHERE CodeWasChanged AND PercentageCoverage < 100
Which classes implement a particular interface?
SELECT TYPES WHERE IsClass AND Implements "System.IDisposable"
Which methods create objects of a particular class?
SELECT METHODS WHERE CreateA "MyNamespace.MyClass"
Which methods assign a particular field?
SELECT METHODS WHERE IsDirectlyWriting "MyNamespace.MyClass.m_Field"
What are the 10 most complex methods?
SELECT TOP 10 METHODS ORDER BY CyclomaticComplexity
Which public methods could be declared as private?
SELECT METHODS WHERE IsPublic AND CouldBePrivate
Which complex method is not enough commented?
SELECT METHODS WHERE CyclomaticComplexity > 15 AND PercentageComment < 10

You can also be warned automatically when a CQL query returns a certain result. In this way, CQL queries become custom rules such as:

I don’t want that my User Interface layer to depend directly on the DataBase layer:
WARN IF Count > 0 IN SELECT NAMESPACES WHERE IsDirectlyUsing "DataLayer" AND NameIs "UILayer"
Static fields should not be named m_XXX (Custom naming conventions):
WARN IF Count > 0 IN SELECT FIELDS WHERE NameLike "^m_" AND IsStatic
Methods out of MyAssembly and MyAssembly2 should not have more than 30 lines of code:
WARN IF Count > 0 IN SELECT METHODS OUT OF ASSEMBLIES "MyAssembly1", "MyAssembly2" WHERE NbLinesOfCode > 30
Public methods should not be removed to avoid API breaking changes:
WARN IF Count > 0 IN SELECT METHODS WHERE IsPublic AND IsInOlderBuild AND WasRemoved
Types tagged with the attribute MyNamespace.FullCoveredAttribute must be thoroughly covered by tests:
WARN IF Count > 0 IN SELECT TYPES WHERE HasAttribute "MyNamespace.FullCoveredAttribute" AND PercentageCoverage < 100

Writing CQL queries and constraints is straightforward both because it is a SQL-like langage and because VisualNDepend provides a CQL editor which supports intellisense and verbose compile error description.

See an online demo about CQL in action (3mn).

Compare Builds

In software development, products are constantly evolving. Hence, developers and architects must pay attention to modifications in code bases. Modern source code repositories handle incremental development. They can enumerate differences between 2 versions of source code files.

NDepend can tell you what has been changed between 2 builds but it does more than simple text comparison. It can distinguish between comment change and code change, between what has been added/removed and what has just been modified. With NDepend, you can see how code metrics are evolving and you know if coupling between components is increasing or not. NDepend can also continuously check modifications to warn you as soon as a breaking compatibility change appears.

See an online demo about the Compare Builds feature (4mn).

82 code metrics

There are many ways to measure a code base. The most common way is to count the number of lines of code. This metric gives a rough estimation of the effort that had been put in to develop the code base. It also allows you to obtain a quality level agreement by pinpointing fat methods and classes.

NDepend counts the number of lines of code. It also comes with 82 other code metrics. Some of them are related to your code organization (the number of classes or namespaces, the number of methods declared in a class...), some of them are related to code quality (complexity, percentage of comments, number of parameters, cohesion of classes, stability of assemblies...), some of them are related to the structure of code (which types are the most used, depth of inheritance...) and some of them are related to code coverage (%coverage, number of lines of code covered, branch coverage...).

NDepend also provides some facilities that will help you to detect metric anomalies and to fix your own thresholds. The VisualNDepend UI displays an interactive view of the architecture of your .NET applications. Such a view can be tuned according to numerous software metrics and can be saved in a PNG file in order to let you print posters.

See an online demo about VisualNDepend basics and Metric view features (3mn).

Manage Complexity and Dependencies

It is vital information to know how the elements of a code base depend on each other. As a developer you spend time thinking about how your layers should interact, creating interfaces and events to avoid dependencies between concrete classes.

As the code base grows, more and more time is spent managing and analyzing dependencies. If I refactor this piece of code, what will be the global impact? Is this layer allowed to access directly DB? Will I accidentally freeze the UI thread if my code invokes this method?

NDepend comes with several facilities that allow the efficient dependency management. In seconds you can know which part of the code will be impacted if you refactor a class, you can be advised if a layer dependency violation has been accidentally created, you can pinpoint precisely which part of the code relies on a particular tier component, you can list methods that can be reached from a given method etc…

See an online demo about Dependencies management (4mn).

Detect Dependency Cycles

The easiest way to keep a code base clean is to avoid dependency cycles between its components. Components are useful to partition a huge amount of code into smaller and understandable pieces. If a dependency cycle involves N components, these N components represent a single super-component. Indeed, the benefits of having N smaller components are lost: any component can be potentially broken by a change in any of the others components, you cannot unit test a component in isolation from the N-1 other ones and finally, all N components must be versioned and deployed all together.

Whether you consider that your components are classes, namespaces, assemblies or a mix in between, NDepend detects dependency cycles between them. It can also help you to find the right way to get rid of a particular dependency cycle. Once dependency cycles have been removed, NDepend can continuously check your code base to warn you as soon as a cycle is accidentally created.

White paper: Control component dependencies

See an online demo that explains how to remove dependency cycles with NDepend (5mn).

Harness Test Coverage Data

Writing automatic tests is a central practice to increase code correctness. Knowing which part of the code is covered by automatic tests helps improving tests and consequently, it helps increasing code correctness.

NDepend gathers code coverage data from NCover™ and Visual Studio Team System™. From this data, NDepend infers some metrics on methods, types, namespaces and assemblies : PercentageCoverage, NbLinesOfCodeCovered, NbLinesOfCodeNotCovered and BranchCoverage (from NCover only).

These metrics can be used conjointly with others NDepend features. For example you can know what code have been added or refactored since the last release and is not thoroughly covered by tests. You can write a CQL constraint to continuously check that a set of classes is 100% covered. You can list which complex methods need more tests.

See an online demo about how to harness test coverage data (3mn).

Enforce Immutability and Purity

At runtime, program’s states are instance and static fields’ values. Controlling how/when/why states are changing is one of the most challenging programming task. This becomes incredibly difficult in multi-threaded environment. This is because potential side-effects due to a state change get too complicated to be understood.

Object-Oriented developers get more and more inspired by the functional programming approach where most states are immutable. An object is immutable if its state doesn’t change once it has been created. A method is pure if its execution doesn’t change any field state. Immutable objects and pure methods are two efficient ways to limit unexpected side-effects.

Through some dedicated CQL conditions and rules, NDepend lets assert immutability and purity on your classes and methods. The best place to start with this feature is to look at the list of default CQL constraint and to read the associated documentation.

See an online demo about how to rationalize Multi-Threaded code (3mn).

Warnings about the health of your Build Process

NDepend is able to provide useful information about the health of your build process, including:

Assemblies versionning issues such as:

AssemblyA references AssemblyB v2.1 but only AssemblyB v2.0 is available.
AssemblyA references 2 versions of AssemblyB (which is not necessarily a bad thing, but it's still useful to be aware of such situation).

Assembly conflicts such as:

The name of my assembly main module file is different from the logical name of my assembly.
Several different assemblies with the same name can be found (different = different hash code and/or different version).

PDB files issues such as:

Missing PDB files.
PDB files and code source files not in-sync.
PDB files and assemblies are not in-sync.

Coverage files issues such as:

Corrupted or missing coverage files.
Coverage files and code source files not in-sync.
Coverage files and assemblies are not in-sync.

See an online demo about Warning management and Report generation (2mn).

Generate custom reports from your Build Process

NDepend can analyze source code and .NET assemblies through NDepend.Console.exe. Each time it analyzes a code base, NDepend yields a report that can inform you about the status of your development. You can customize sections shown in the report and you can even provide your own XSL sheet for full customization.

You can also build your own set of CQL constraints that will be checked at each analysis. The report will warn you each time a constraint is violated. This feature makes automatic design and quality regression test a reality.

You might want to integrate NDepend analysis into your build process. This way, you will be advised regularly of the status of your development and NDepend will continuously check for the violation of CQL constraints. NDepend comes with facilities to help integration with your build process made with MSBuild, NAnt and CruiseControl.NET.

See an online demo about integrating facilities to integrate NDepend into your build process (1mn30).
See an online demo about how to customize reports (1mn30).

Diagrams

NDepend outputs several kind of diagrams


Treemap metric	Abstracness vs. Instability	Dependencies matrix	Dependencies graph

Facilities to cope with real-world environment

NDepend is non-intrusive. You don’t have to modify or to recompile your code to use it.

NDepend is easy to tackle with. It won’t take you more than 5 minutes to build a NDepend project to analyze a .NET application with dozens of assemblies.

NDepend is optimized. It analyses up to 3.500.000 IL instructions (~ 500.000 lines of C# or VB.NET code) per minute.

NDepend collaborates with Visual Studio™ 2005 and 2008. You can have access to all NDepend menus by right-clicking code elements and projects in VisualStudio™ and the VisualNDepend UI allows you to open code element definitions in Visual Studio™.

NDepend collaborates with Reflector. You can have access to all NDepend menus by right-clicking code elements in Reflector and the VisualNDepend UI allows you to open code element definitions in Reflector.