NDepend v4 Released   Download Free Trial 14-Day Fully Functional Now!
Ignorer les liens de navigation
Home
Download
Product ▼
Purchase
Upgrade
Documentation ▼
About ▼

Features

Custom Rule and Code Query
 
   Support for Code Query over LINQ (CQLinq) to easily write custom rules and query code.


     NDepend.API and Power Tools
 
   Write your own static analyzer based on NDepend.API, or tweak existing open-sources Power Tools.

     Harness Test Coverage Data
 
   Import test coverage data, and make the most of it in the NDepend feature-rich context.


Code Quality, 82 Code Metrics
 
   Lines of Code, Cyclomatic Complexity, Coupling, Nesting Depth, Rank, NDepend supports them all (and much more).

     Explore Existing Architecture
 
   Explore how the code is actually structured and shed light on architectural flaws kept secret.


     Detect Dependency Cycles
 
   Get rid of dependency cycles between components to achieve higher code maintainability.


Compare Builds and Code Diff
 
   Compare two versions of a code base and browse code diff and changes in any way you can think of.

     Enforce Immutability and Purity
 
   NDepend helps maintaining clean side-effects free code to achieve clean concurrent programming.


     Complexity and Diagrams
 
   Spot too complex code at a glance thanks to unique diagramming capabilities in the .NET world.

Continuous Integration Reporting
 
   Integrate NDepend analysis into your build process and get highly customized and detailed reports to see progression and prevent code quality degradation.
     Warnings on Build Process Health
 
   Be warned of potential build process problems before they end up causing friction and pain.


     Real-World Proof
 
Full Visual Studio integration, .NET Reflector support, super fast and lightweight analysis, NDepend is conceived for real-world programmers.

| Share

 Follow us on Twitter


Watch a Video Tour!
Getting Started
Product Features

        Code Query LINQ

NDepend Overview Tour


▲ Go to List of Features    -    ► Download Free Trial Now!
Code Rule and Code Query over LINQ (CQLinq)

NDepend lets query the code base over LINQ queries thanks to CQLinq.
For example the following CQLing query matches all public methods that have more than 30 lines of code:
from m in Application.Methods  
where m.NbLinesOfCode >  30  && m.IsPublic
select m
Around 200 default queries and rules are provided when you create a new NDepend project. They are easy to read and easy to adapt to your need.
Writing CQLinq queries and constraints is straightforward both because it is C# LINQ syntax and because NDepend provides a CQLinq editor which supports:
  • code completion / intellisense
  • live compile error description
  • integrated tooltip documentation


Also, once the query is compiled, it gets executed immediately and its result is well displayed and browsable:


Powerful and elaborated queries and rules can be written with CQLinq, like the following one for example:
// <Name>UI layer shouldn't use directly DB types</Name>
warnif count > 0

// UI layer is made of types in namespaces using a UI framework
let uiTypes = Application.Namespaces.UsingAny(
                 
Assemblies.WithNameIn("PresentationFramework", "System.Windows", 
                                       
"System.Windows.Forms", "System.Web")
              
).ChildTypes()

// You can easily customize this line to define what are DB types.
let dbTypes = ThirdParty.Assemblies.WithNameIn("System.Data", "EntityFramework", "NHibernate").ChildTypes()
              
.Except(ThirdParty.Types.WithNameIn("DataSet", "DataTable", "DataRow"))

from uiType in uiTypes.UsingAny(dbTypes)
let dbTypesUsed = dbTypes.Intersect(uiType.TypesUsed)
select new { uiType, dbTypesUsed }

But short CQLinq queries can be written (or even generated) to get some immediate answers to questions about a code base:
  • Is the code layered correctly?
    from n in Namespaces where n.Level == null select n
    
  • Which methods have been refactored since the last release and are not thoroughly covered by tests?
    from m in Application.Methods where 
    m.CodeWasChanged()  &&  m.PercentageCoverage <  100
    select new { m, m.PercentageCoverage } 
  • Which classes implement a particular interface?
    from t in Types 
    where t.IsClass && t.Implement("System.IDisposable")
    select t
  • Which methods create objects of a particular class?
    from m in Methods where m.CreateA ("MyNamespace.MyClass") select m
    
  • Which methods assign a particular field?
    from m in Methods 
    where m.AssignField("MyNamespace.MyClass.m_Field")
    select m
  • What are the 10 most complex methods?
    (from m in Methods 
     
    orderby m.CyclomaticComplexity
     
    select new { m, m.CyclomaticComplexity }).Take(10) 
  • Which method could have a more restricted visibility?
    from m in Application.Methods 
    where m.Visibility != m.OptimalVisibility
    select new { m, 
                 
    m.Visibility , 
                 
    CouldBeDeclared = m.OptimalVisibility,
                 
    m.MethodsCallingMe }
  • Which complex method is not enough commented?
    from m in Application.Methods 
    where m.CyclomaticComplexity >  15 && m.PercentageComment <  10
    select new { m, m.CyclomaticComplexity, m.PercentageComment }


You can also be warned automatically when a CQLinq query returns a certain result. Such a CQLinq code query is actually a code rule such as:
  • I don’t want that my User Interface layer to depend directly on the DataBase layer:
    warnif count > 0 
    from n in Namespaces 
    where n.IsUsing("DataLayer") && (n.Name == @"UILayer")
    select n
  • Static fields should not be named m_XXX (Custom naming conventions):
    warnif count > 0 
    from f in Fields where f.NameLike (@"^m_") && f.IsStatic
    select f
  • Methods out of MyAssembly and MyAssembly2 should not have more than 30 lines of code:
    warnif count > 0  
    from  m in Application.Assemblies.WithNameNotIn("MyAssembly1", "MyAssembly2").ChildMethods() 
    where m.NbLinesOfCode > 30
    select new { m, m.NbLinesOfCode }
  • Public methods should not be removed to avoid API breaking changes:
    warnif count > 0 
    from m in codeBase.OlderVersion().Application.Methods 
    where m.IsPublic && m.WasRemoved()
    select m
  • Types tagged with the attribute MyNamespace.FullCoveredAttribute must be thoroughly covered by tests:
    warnif count > 0  
    from  t in Application.Types 
    where t.HasAttribute ("NDepend.Attributes.FullCoveredAttribute") && 
          
    t.PercentageCoverage <  100
    select new { t, t.PercentageCoverage }
Related Documentation::
Default CQLinq Rules
CQLinq Syntax
CQLinq Features
CQLinq Performance
CQL to CQLinq Conversion
Declare CQLinq rules in C# or VB.NET source code


▲ Go to List of Features    -    ► Download Free Trial Now!
NDepend.API and Power Tools

The CQLinq code querying possibility is based on an open API proposed by NDepend and named NDepend.API. NDepend.API goes further than just code querying and ruling. It is also designed to create NDepend project, start programmatically NDepend analysis, generate on the fly and execute CQLinq rules or queries.

NDepend.PowerTools are a set of short open-source static analyzers based on NDepend.API. They are packed into the Visual Studio solution $NDependInstallPath$\NDepend.PowerTools.SourceCode\NDepend.PowerTools.sln. The power tools proposes a wide variety of features, from search for duplicate code, facilities for code review to public API breaking changes detection.

Related Documentation::
NDepend.API Introduction
NDepend.API Overview
NDepend.API Getting Started


▲ Go to List of Features    -    ► Download Free Trial Now!
Compare Builds and Code Diff

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).
Related Links::
Avoid API breaking changes
How to avoid regression bugs while adding new features
Ensure the quality of the code that will be developed this year
Are you sure added and refactored code is covered by tests?
Reporting Code Diff


▲ Go to List of Features    -    ► Download Free Trial Now!
Code Quality, 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).
Related Links::
How do you count your number of Lines Of Code (LOC) ?
Why is it useful to count the number of Lines Of Code (LOC) ?
Layering, the Level metric and the Discourse of Method
Code metrics on Coupling, Dead Code, Design flaws and Re-engineering
A simple trick to code better and to increase testability
Interview of our Lead Developer by Scott Hanselman about Metrics (35mn)


▲ Go to List of Features    -    ► Download Free Trial Now!
Build Process / Continuous Integration / Reporting

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 CQLinq rules 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 CQLinq rules. NDepend comes with facilities to help integration within your build process, whatever the Build Process technology you are using.
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).
Related Links::
NDepend.Console.exe command line arguments
NDepend Analysis
Customize NDepend Report
Sample NDepend Reports
Critical Rules and Build Failure
NDepend Analysis Inputs: Detailled explanations about what are NDepend analysis inputs and how NDepend process them.
Source Files Rebasing: Explains how to rebase files analyzed by NDepend.

Integrate NDepend with TFS
Integrate NDepend with CruiseControl.NET
Integrate NDepend with Team City
Integrate NDepend with FinalBuilder


▲ Go to List of Features    -    ► Download Free Trial Now!
Explore Existing Architecture

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).
Related Links::
Exploring Existing Code Architecture in Visual Studio
Dependency Structure Matrix
Two White Books on partitioning .NET code through assembly and namespace
Deconstructing Software
Fighting Fabricated Complexity
Identify Code Structure Patterns at a Glance
Hints on how to componentize existing code
Dependencies and Concerns
All Paths from A to B
Understanding Code: Static vs Dynamic Dependencies


▲ Go to List of Features    -    ► Download Free Trial Now!
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).
Related Links::
Keep your code structure clean
Layering, the Level metric and the Discourse of Method
Re-factoring, Re-Structuring and the cost of Levelizing


▲ Go to List of Features    -    ► Download Free Trial Now!
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 CQLinq rule 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).
Related Links::
Coverage FAQ
Make the most of your test coverage data
Are you sure your added and refactored code is covered by tests?
Dealing with code uncoverable by tests
High Test Coverage Ratio is a good thing, Anyway!

▲ Go to List of Features    -    ► Download Free Trial Now!
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 CQLinq 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 CQLinq rules and to read the associated documentation.
See an online demo about how to rationalize Multi-Threaded code (3mn).
Related Links::
Immutable types: understand their benefits and use them
Manage state in a multi-threaded environment


▲ Go to List of Features    -    ► Download Free Trial Now!
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).
    Related Links::

    NDepend Analysis
    Customize NDepend Report
    Sample NDepend Reports


    ▲ Go to List of Features    -    ► Download Free Trial Now!
    Diagrams

    NDepend outputs several kind of diagrams

    Treemap metric Abstracness vs. Instability Dependencies matrix Dependencies graph




    ▲ Go to List of Features    -    ► Download Free Trial Now!
    Facilities to cope with Real-World Environment

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

    • NDepend is easy to tackle with. It won’t take you more than 5 minutes to install it as a VisualStudio addin and analyze a .NET application with dozens of assemblies.

    • NDepend is fast and lightweight. A tremendous effort has been spend on optimization.
      • It analyze around 10.000 lines of C# or VB.NET code per second,
      • Most of analysis will take less than 5 seconds (asynchronous) in Visual Studio thanks to incremental analysis capability,
      • It takes from 20MB to 50MB of extra memory in a Visual Studio process.

    • NDepend is 100% integrated in Visual Studio™ 2010, 2008 and 2005. If you prefer you can use the standalone VisualNDepend UI that collaborates with Visual Studio™.

    • NDepend collaborates with Reflector. You can have access to all NDepend menus by right-clicking code elements in Reflector and with NDepend, Visual Studio and Reflector smartly collaborates.


    Related Link::
    Source Files Rebasing
    Reflector v6 and NDepend collaboration

    ▲ Go to List of Features    -    ► Download Free Trial Now!
    Copyright © 2004-2013 Patrick Smacchia