What's new in NDepend v4.0
The biggest NDepend milestone ever!
  • NDepend v4.0 proposes seamless code query and rule over LINQ thanks to CQLinq.
    More than 60 new CQLinq default code rules are proposed.
    Most of previous CQL default rules have been enhanced and a CQL to CQLinq automatic converter tool is available.

  • CQLinq is based on the new NDepend.API code model.
    14 open-sources Power Tools developed on top of NDepend.API are available.
    It is easy to create your own Power Tool or adapt existing ones.

  • NDepend v4.0 integrates into Visual Studio 2012, 2010 and 2008


  • Concerning the new CQLinq query language, I simply cannot overstate how much better it is to use than the old CQL queries. The NDepend team has done a tremendous job! I was able to solve my particular problem in no time, even though I started from scratch. I’m definitely going to buy the version 4 upgrade as soon as possible.
    Spontaneous feedback from Carl-Johan Berg .NET Developer at AMF Sweden

CQLinq: Code Query and Rule over LINQ

NDepend.API and Power Tools
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.



Polished CQLinq query and rule editor with:
  • CQLinq editor with code completion / intellisense
  • Integrated tooltip documentation
  • Live compile error description
Because your time is precious, CQLinq is very fast with around 100 queries compiled and executed per second.



CQLinq Syntax
CQLinq Features
CQLinq Performance
CQL to CQLinq Conversion



Most of existing CQL default rules enhanced

  • Types with too many methods
  • Types with too many fields
  • A stateless class or structure might be turned into a static type
  • Class shouldn't be too deep in inheritance tree
  • API Breaking Changes: Methods
  • API Breaking Changes: Types
  • API Breaking Changes: Fields
  • API Breaking Changes: Interfaces
  • Potentially dead Types
  • Potentially dead Methods
  • Potentially dead Fields
  • Types tagged with ImmutableAttribute must be immutable
  • Methods tagged with PureAttribute must be pure
  • Property Getters should be immutable
  • Avoid methods with name too long
  • Avoid types with name too long
  • Avoid fields with name too long
  • Interface name should begin with a 'I'
  • All 30 .NET Framework Usage rules
  • 14 Open-Source Power Tools based on NDepend.API:


    NDepend.API Introduction
    NDepend.API Overview
    NDepend.API Getting Started


    More than 60 new CQLinq default code rule

    All CQLinq default rules

  • Base class should not use derivatives
  • Do not hide base class methods
  • Types with disposable instance fields must be disposable
  • Disposable types with unmanaged resources should declare finalizer
  • Overrides of Method() should call base.Method()
  • Methods should be declared static if possible
  • Non-static classes should be instantiated
  • Constructor should not call a virtual methods
  • Don't assign static fields from instance methods
  • Avoid types initialization cycles
  • Avoid the Singleton pattern
  • Avoid custom delegates
  • Avoid namespaces mutually dependent
  • Avoid namespaces dependency cycles
  • Avoid partitioning the code base through many small library Assemblies
  • Avoid public methods not publicly visible
  • Constructors of abstract classes should be declared as protected or private
  • Equals() should be overridden by types implementing the '==' operator
  • UI layer shouldn't use directly DB types
  • UI layer shouldn't use directly DAL layer
  • Avoid public methods not publicly visible
  • Methods that could have a lower visibility
  • Broken serializable types
  • Heuristic to find types moved from one namespace or assembly to another
  • C.R.A.P method code metric
  • Avoid decreasing code coverage by tests of types
  • Types that used to be 100% covered but not anymore
  • Avoid making complex methods even more complex
  • Avoid making large methods even larger
  • Avoid adding methods to a type that already had many methods
  • Avoid adding instance fields to a type that already had many instance fields
  • Avoid transforming an immutable type into a mutable one
  • Avoid transforming an immutable field into a mutable one
  • Types tagged with ImmutableAttribute must be immutable
  • Avoid static fields with a mutable field type
  • A field must not be assigned from outside its parent hierarchy types
  • Don't use obsolete types, methods or fields
  • Don't use dangerous threading methods
  • Don't tag instance fields with ThreadStaticAttribute
  • Don't forget to implement methods that throw NotImplementedException
  • Don't call your method Dispose
  • Methods prefixed with 'Try' should return a boolean
  • Avoid having different types with same name
  • Avoid prefixing type name with parent namespace name
  • Avoid naming types and namespaces with the same identifier
  • Public methods returning a reference needs a contract to ensure that a non-null reference is returned
  • Test Methods
  • Methods directly called by test Methods
  • Methods directly and indirectly called by test Methods
  • Types directly using one or several types changed
  • Types indirectly using one or several types changed
  • Methods directly calling one or several methods changed
  • Methods indirectly calling one or several methods changed
  • Higher cohesion - lower coupling
  • Avoid referencing source file out of Visual Studio project directory
  • Avoid duplicating a type definition across assemblies
  • Namespace name should correspond to file location
  • Avoid defining multiple types in a source file
  • Types with source files stored in the same directory, should be declared in the same namespace
  • Types declared in the same namespace, should have their source files stored in the same directory