Dependency Graph

• This diagram represents the Graph of Dependencies beetween the .NET assemblies of your application.
• This static diagram can be useful but it is just a coarse view of your application architecture.
• It is recommended to use the NDepend interactive dependency Graph and interactive Dependency Matrix for an in-depth exploration of the actual architecture of your code.
  

Online documentation:

• NDepend Interactive Dependency Graph
• NDepend Interactive Dependency Matrix

Dependency Matrix

• This diagram represents the DSM (Dependency Structure Matrix) beetween the .NET assemblies of your application.
• The Dependency Matrix is a compact way to represent and navigate across dependencies between components.
• The number on cells of the Dependency Matrix included in the report, represent the number of types involved in the coupling
• It is recommended to use the NDepend interactive dependency Graph and interactive Dependency Matrix for an in-depth exploration of the actual architecture of your code.

Online documentation:

• NDepend Interactive Dependency Matrix
• NDepend Interactive Dependency Graph

Visualizing Code Metrics through Treemaping

• In this Metric View, the code base is represented through a Treemap.
• Treemapping is a method for displaying tree-structured data by using nested rectangles.
• In the present treemap, each rectangle represents a method and the area of a rectangle is proportional to the number of lines of code of the corresponding method.

With the Online documentation, understand how Treemaping can help you see patterns in your code base, that would be hard to spot with other ways.

• Visualizing Code Metrics with Treemap

Abstractness versus Instability Diagram

The Abstractness versus Instability Diagram helps to detect which assemblies are potentially painful to maintain (i.e concrete and stable) and which assemblies are potentially useless (i.e abstract and instable).

• Abstractness: If an assembly contains many abstract types (i.e interfaces and abstract classes) and few concrete types, it is considered as abstract.
  
• Stability: An assembly is considered stable if its types are used by a lot of types of tier assemblies. In this conditions stable means painful to modify.

Online documentation:

• Definitions of related Code Metrics

For beginners: Where to start

• Search for unwanted dependencies.
• Look for complex methods listed through the standard Rule Quick Summary of methods to refactor.
• Inspect other standard Rules that were violated.
• See how standard Rules are written and customize some Rules to your needs.
• Look at Code Metrics definitions to see how Code Metrics can help increase code quality.
• Use the Code Diff feature to review code changes (pro edition only).
• Import test coverage data to assess possible improvements in your testing strategy (pro edition only).

Quick Tips

• In addition to the NDepend report, use the interactive UI through the standalone executable VisualNDepend.exe, or through the Visual Studio NDepend Addin.
• With the interactive UI, browse more detailed data and have Rules checking updated each time the code is modified and recompiled.
• The analysis execution and the report options are configurable through the interactive UI, in the panel Project Properties.
• Plain HTML report (single HTML page, no javascript, no menu) is also available.
• Full NDepend documentation is available on the NDepend website under the Documentation menu.

Code Quality from Now!

• On a large existing code base, the NDepend set of default rules will likely report thousands of flaws and imperfections.
• It is not possible to stop development for several weeks to fix all flaws, and then resume development on a clean code base.
• NDepend has support for the Code Quality from Now! strategy. The idea is to ensure that flaws are fixed only on code added and eventually, on code refactored as well.
• The first thing to do is to capture the current state of the code base and set it as a Baseline for Comparison.
• The second thing to do is to adapt and customize Rules to the Code Quality from Now! strategy. Concretely you just need to append the clause && (codeElement.WasAdded() || codeElement.CodeWasChanged()) to a rules to get it checked only on new and refactored code.
• For example, the following rule reports only added and refactored too complex methods.
  // <Name>From now, all methods added or refactored must be not too complex</Name>
  warnif count > 0 
  from m in Methods where
      m.CyclomaticComplexity > 20 && (m.WasAdded() || m.CodeWasChanged())
  select m
• Another example is to ensure that all new or refactored types respect a minimum of ratio of code coverage by tests.
  // <Name>From now, all types added or refactored should be 70% covered by tests</Name>
  warnif count > 0 
  from t in Types where
      t.PercentageCoverage < 70 && (t.WasAdded() || t.CodeWasChanged())
  select t