NDepend – Improve Your .NET Code Quality Fast
Introduction
A build that's green doesn't mean the architecture underneath it is healthy - a compiler doesn't care whether two layers that shouldn't know about each other have quietly become tangled, or whether one class has grown into a 2,000-line dumping ground. NDepend analyzes the actual dependency graph and metrics of a .NET solution and surfaces exactly that kind of problem, the ones code review alone tends to miss because they only show up in aggregate.
🎬 Watch the full video here:
The dependency graph is the headline feature
NDepend builds a visual graph of which assemblies, namespaces, and types depend on which - and specifically highlights dependency cycles, where module A depends on B which depends back on A, directly or transitively. A cycle like that means neither module can be understood, tested, or replaced independently of the other, even if nobody intended it to happen that way - it usually accumulates one small "just this one reference" decision at a time.
Code metrics that actually predict risk
Beyond a simple line count, NDepend surfaces metrics with real predictive value for where bugs cluster:
- Cyclomatic Complexity - the number of independent paths through a method; high values correlate with harder-to-test, harder-to-reason-about code.
- Afferent/Efferent Coupling - how many other types depend on this one (afferent) versus how many types this one depends on (efferent) - a type with high afferent coupling is risky to change since everything downstream feels it.
- LCOM (Lack of Cohesion of Methods) - a high value suggests a class doing several unrelated jobs and is a candidate to split.
CQLinq: querying your own codebase like a database
The distinctive feature is CQLinq - LINQ queries run directly against your code's structure, letting you write and enforce your own architectural rules instead of only relying on built-in ones:
from t in JustMyCode.Types
where t.NbLinesOfCode > 500
select new { t, t.NbLinesOfCode }
This one flags every class over 500 lines. A more architectural rule enforces layering directly - failing the build if, say, the domain layer ever references the infrastructure layer:
from t in Application.Types
where t.DependsOn("MyApp.Infrastructure")
select t
Once these live in CI, "don't let the domain layer depend on infrastructure" stops being a rule someone has to remember during code review and becomes something the build enforces.
Trend charts across builds
Run against CI on every build, NDepend tracks metrics over time rather than as a single snapshot - a rising trend in average cyclomatic complexity, or a slowly growing count of dependency cycles, is visible as a trend line long before either becomes a crisis. This is the difference between "we know quality is degrading" as a feeling and having an actual chart showing it.
Common pitfalls
- Running the analysis once and never again. The trend over time is more valuable than any single snapshot.
- Trying to fix every flagged issue at once. Triage by what's actually risky (high coupling, real cycles) versus cosmetic metric thresholds.
- Writing CQLinq rules nobody on the team understands or maintains. Keep custom rules few and well-documented.
- Ignoring dependency cycles because "it still compiles." Compiling fine and being maintainable are different properties.
- Not integrating it into CI, which turns the tool into an occasional audit rather than a continuous quality gate.
Key Takeaways
- NDepend's dependency graph surfaces cycles between modules that compile fine but quietly damage maintainability.
- Metrics like cyclomatic complexity, coupling, and LCOM have real predictive value for where bugs and hard-to-change code cluster.
- CQLinq lets you write and enforce custom architectural rules (layering, size limits) as LINQ queries against your own code.
- Running the analysis in CI and tracking metrics over time catches degrading quality as a trend, not just a one-off audit.
Get the Full Source Code
The complete runnable solution - the sample solution analyzed in the video, plus the CQLinq rules shown - is available to Patreon supporters. If you want the layering and size-limit rules ready to adapt to your own codebase instead of rebuilding them from the walkthrough above, you can find it on Patreon.