NDepend is the only Visual Studio extension that is able to tell the developer that over the past hour, the code just written has introduced debt that would cost for example about 30 minutes should it have to be repaid later. Knowing this, the developer can fix the code before even committing it to the source control.

With NDepend code rules are C# LINQ queries that can be created and customized in a matter of seconds. These queries contain C# formulas to compute accurate technical debt estimations.

The default rule-set offers over a hundred code rules that detect a wide range of code smells including entangled code, dead-code, API breaking changes and bad OOP usage.

As a static analyzer, NDepend will likely find hundreds or even thousands of issues affecting a real-world code base. Stopping work to attempt to fix all issues for weeks would be quite unproductive.

This is why NDepend is the only tool that offers a baseline in Visual Studio. The tool estimates the Technical Debt progress since the baseline.
Recent code smells that should be fixed before committing any code to source control are highlighted in Visual Studio. They can then be fixed even before reaching the source server.

As a consequence the Code Quality remains under control with no major upfront investment.

A Quality Gate is a code quality criterion that must be enforced before releasing and eventually, before committing to source control.
A dozen of default Quality Gates are continuously checking measures such as overall Code Coverage by tests or extra Technical Debt since baseline.

With NDepend, a Quality Gate is a C# LINQ query easy to customize and create. This unique approach offers the required level of flexibility to enforce what really matters for your organization.

We don't sell consultancy, we sell software. Our goal is to offer a seamless tool which is easy to get started with and easy to live with. With NDepend, you’ll obtain in-depth reporting within a few minutes after first installation and NDepend results will quickly become essential to take the right decisions.

NDepend integrates smoothly both within Visual Studio (2017, 2015, 2013, 2012, 2010) and Team Services (VSTS). Other DevOps and Continuous Integration tools are also supported (TFS 2013, TeamCity, SonarQube...). All .NET profiles are supported, including .NET Core 2.0.

Interactive and detailed report production is automated from the Continuous Integration process.

Because we know developer time is invaluable, NDepend is fast, very fast

The technical debt can be re-estimated after each compilation in Visual Studio within just a few seconds, even for hundreds of rules passed on a very large code base and, as we are aware of its importance, without any noticeable IDE slow down.

Fixing issues is much easier as the developer is immediately informed with no delay of new issues just created, while the context is still fresh in her mind and while the code is not checked-in yet to the source control server.

Because a picture is worth a thousand words, NDepend proposes several unique ways to visualize your code. This includes:

Trend Charts
Dependency Graph
Dependency Matrix
Code Metrics Colored Treemaping

Code maintainability improves. This positively impacts the productivity of development teams.
Over time, developers get educated about rules to follow and their skills improve.
Architects can anticipate the impact of code changes. The right decisions are taken early.
Since quality is checked automatically and continuously with a strong focus on recent changes, both in Visual Studio and in the DevOps, the team builds better code.
Executives gain control over costs and risks thanks to light being shed on development facts and trends that matter most.

What's new in NDepend v2018.1

Support for .NET Core 2.1 Preview
Applications developed with .NET Core 2.1 Preview can be analyzed.
Here you can read a blog post about spotting new .NET Core 2.1 APIs with NDepend.
Performance improvements for Visual Studio 2017 v15.6 support
The NDepend Visual Studio extension performances have been improved to avoid that Visual Studio 2017 v15.6 flags the NDepend extension as slow.

New support for DDD ubiquitous language check (Domain Driven Design)
The language used in identifiers of classes, methods and fields of the core domain, should be based on the Domain Model. This constraint is known as ubiquitous language in Domain Driven Design (DDD) and it reflects the need to be rigorous with naming, since software doesn't cope well with ambiguity.
A new default rule DDD ubiquitous language check is proposed in the group Naming convention. This rule is disabled per default because its source code needs to be customized to work, both with the core domain namespace name (that contains classes and types to be checked), and with the list of domain language terms.
This rule implementation relies on the new NDepend API extension method ExtensionMethodsString.GetWords(this string identifier) method that extracts terms from classes, methods and fields identifiers in a smart way.

A New Rule and Less False Positives
New default rule Properties and fields that represent a collection of items should be named Items. in the group Naming convention.

The rule Don't call your method Dispose could warn when overriding the Dispose() method of an interface that is not IDisposable, like IHttpModule.Dispose().
The rule Avoid methods with name too long doesn't match anymore test methods because it is considered as a good practice to name unit tests in such a way with a meaningful name.
The rule Types that could be declared as private, nested in a parent type doesn't match anymore types with extension methods that cannot be nested. Also it doesn't advise anymore to nest a base class or a base interface into its unique child class.
The rule Classes that are candidate to be turned into structures now returns mostly true positive. The rule now requires that instance fields of the class must be typed with value-type, requires the class to be immutable and requires the class to have no parameterless constructor.
The rule Avoid empty interfaces doesn't match anymore empty interfaces that implement at least one other interface. Such interface can be considered as not empty, since implementing it means that sub-interfaces members must be implemented.
The rule Overrides of Method() should call base.Method() doesn't match any more properties getters and setters that are not supposed to have enough logic to satisfy this rule constraint.
The rule Methods should be declared static if possible and the 3 queries Test Methods; Methods directly called by test Methods and Methods directly and indirectly called by test Methods now also support the FactAttribute to define a test method.
The rule Instances size shouldn't be too big has been improved to avoid matching classes that derive from some DevExpress components and that derives from classes in System.Component and System.Xml.
Annual interests of issues of the rule Instances size shouldn't be too big is now 10x times higher for structure than for classes, because of the performance penalty to deal with large structure values at runtime.

Other Improvements
New API method ExtensionMethodsString.GetWord(this string identifier) to extract words from code element identifiers (ICodeElement.SimpleName)
New API methods ExtensionMethodsString.Aggregate(this IEnumerable seq, string separator), FirstCharToUpper(this string), StartsWithAny(this string, params string[]), EndsWithAny(this string, params string[]) to ease string manipulation.
All www.ndepend.com urls are now referenced as HTTPS.

[url=https://developer.team/index.php?do=go&url=aHR0cHM6Ly93d3cubmRlcGVuZC5jb20v]

Only for V.I.P [/url]

Warning! You are not allowed to view this text.