What's new in NDepend v4.0

CQLinq: Code Query and Rule over LINQ

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.

• CQLinq editor with code completion / intellisense
• Integrated tooltip documentation
• Live compile error description

• 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

NDepend.API and Power Tools

14 Open-Source Power Tools based on NDepend.API:

• NDepend.API Getting Started
• NDepend.API Documentation

More than 60 new CQLinq default code rule

• 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