Search results Save results for later use

Avoid types too big

Matches types with more than 200 lines of code (JustMyCode methods only): extremely complex to develop and maintain. Maybe a God Class: a class controlling too many others, grown into The Class That Does Everything. NbLinesOfCode metric: https://www.ndepend.com/docs/code-metrics#NbLinesOfCode

How to Fix:

Split into smaller types. Refactoring a God Class takes patience:

- Split the logic into smaller classes (possibly private nested ones the God Class becomes composed of).

- Partition by responsibilities: look for subsets of methods strongly coupled with subsets of fields.

- If mostly logic (few states), consider static classes with only pure static methods (no field read/assigned), which are easily testable.

- Keep the God Class interface at first, delegating to the extracted classes, until it is a pure facade; then keep or discard it.

- Write tests for each method before extracting it.

Estimated Debt: linear from 1 hour (200 loc) to 10 hours (2.000+ loc). Static types with no mutable fields cost less: their static methods are easily moved between types.

Avoid types with too many methods

Matches types with more than 20 methods (constructors, property and event accessors excluded): hard to understand and maintain, symptom of too many responsibilities, maybe a God Class (The Class That Does Everything). Types with only constant fields are skipped: many stateless methods is ok.

How to Fix:

See HowToFix advices of the default rule Types too Big.

Estimated Debt: linear from 1 hour (20 methods) to 10 hours (200+). Static types with no mutable fields cost less: their static methods are easily moved between types.

Avoid types with too many fields

Matches types with more than 15 fields (constants, static-readonly and enumerations excluded): hard to understand and maintain, symptom of too many responsibilities.

How to Fix:

Group subsets of fields into smaller types and dispatch the methods logic into them. More advices in Types too Big, HowToFix section.

Estimated Debt: linear from 1 hour (15 fields) to 10 hours (200+).

Avoid methods too big, too complex

Matches methods where ILNestingDepth > 2 and CyclomaticComplexity > 17: hard to understand and maintain, maybe a God Method (The Method That Does Everything, grown by adding ifs instead of new methods). Metrics: https://www.ndepend.com/docs/code-metrics#CC https://www.ndepend.com/docs/code-metrics#ILNestingDepth

How to Fix:

Split into smaller methods or even new classes. Question each local variable's scope: it may become an instance field of the new class(es). Large switch…case can become types implementing a common interface, polymorphism replacing the switch cases tests. Write tests for each method before extracting it.

Estimated Debt: 20 minutes to 3 hours, linear in a weighted complexity score.

Avoid methods with too many parameters

Matches methods with 8 or more parameters: painful to call, possible performance cost. NbParameters metric: https://www.ndepend.com/docs/code-metrics#NbParameters

Overrides of third-party methods and constructors calling a base constructor with 8+ parameters are skipped (lower-level problem).

How to Fix:

Add properties/fields to the declaring type, or pass a dedicated arguments class/structure (e.g. System.Diagnostics.ProcessStartInfo passed to System.Diagnostics.Process.Start(ProcessStartInfo)).

Estimated Debt: linear from 1 hour (8 parameters) to 6 hours (40+).

Avoid methods with too many overloads

Matches sets of methods with 7 overloads or more, typically introduced to accommodate combinations of input parameters: hard to maintain, ambiguous, less readable.

The visitor design pattern http://en.wikipedia.org/wiki/Visitor_pattern requires a Visit() overload per sub type, so overloads starting with "visit" or "dispatch" (case-insensitive) are skipped; adapt to your naming convention. Sometimes many overloads are fine, e.g. a conversion method covering all numeric types. NbOverloads metric: https://www.ndepend.com/docs/code-metrics#NbOverloads

Overrides of third-party methods and constructors calling a base constructor are not counted (lower-level problems).

How to Fix:

Use optional parameters, named arguments or a parameter array (params) instead.

Estimated Debt: 3 minutes per method overload.

Avoid methods potentially poorly commented

Matches methods with less than 10% comment lines and at least 20 lines of code; they might need more comments. Only comments in the method body are counted. Comments metrics: https://www.ndepend.com/docs/code-metrics#PercentageComment https://www.ndepend.com/docs/code-metrics#NbLinesOfComment

How to Fix:

Typically add comments — though clean code with well-named variables and methods, plus unit-tests, needs few comments. However hacks (non-trivial code circumventing API limitations or bugs) must absolutely be commented: intention, need, and source of the solution.

Estimated Debt: linear from 2 minutes (10 uncommented loc) to 20 minutes (200+).

Avoid types with poor cohesion

Matches types with Lack Of Cohesion of Methods (LCOM, range [0-1]) higher than 0.84: a poorly cohesive class. A class is utterly cohesive when all its methods use all its instance fields. Only types with enough methods and fields are matched to avoid bias. LCOM metric: https://www.ndepend.com/docs/code-metrics#LCOM

How to Fix:

Split the type into smaller, more cohesive types implementing the same logic. Right-click a matched type > "Show on the Dependency Graph" to visualize fields usage by methods and plan the refactoring.

Estimated Debt: linear from 5 minutes (low poorCohesionScore) to 4 hours (high).

Avoid methods with too many local variables

Matches methods with more than 15 variables: extremely complex, must be refactored (methods with more than 8 are already hard to maintain).

Variables are counted from compiled IL; compilers may add hidden variables (e.g. for lambdas), hence the threshold of 15 to avoid false positives.

How to Fix:

Split the method into smaller methods or even new classes. Question each local variable's scope: it may become an instance field of the new class(es).

Estimated Debt: linear from 10 minutes (15 variables) to 2 hours (80+).

Avoid unmaintainable code

Detects methods with a low maintainability index and high cyclomatic complexity: hard to understand, error prone and risky to modify. Metrics definitions:

https://www.ndepend.com/docs/code-metrics#MaintainabilityIndex

https://www.ndepend.com/docs/code-metrics#CC

https://www.ndepend.com/docs/code-metrics#HalsteadVolume

How to Fix:

Refactor the method by splitting it into smaller, more focused components.

From now, all types added should respect basic quality principles

Runs only in diff mode (baseline defined), on types added since baseline (easily modified to also match refactored types).

Matched types violate basic quality principles: too many methods, too many fields, or too many types used — often symptoms of too many responsibilities. Constructors, property/event accessors, constant and static-readonly fields, and enumerations are not counted.

How to Fix:

Split the type into smaller types implementing the same logic together.

Constant 10 minutes Debt: the fix effort is already estimated by the Code Smells rules. But severity is High, higher for new types: the time to improve them is now, before the next production release.

From now, all types added should be 100% covered by tests

Runs only in diff mode (baseline defined) and when coverage data is imported, on types added since baseline (easily modified to also match refactored types) not fully covered by tests.

The last ~10% of a class is as hard to cover as the first 90%, so teams often settle for 90%. But untestable code usually means poorly written, error prone code: most tricky bugs might come from this small portion of hard-to-test code. Not all classes need 100% coverage (e.g. UI), but most of the application logic should live in easy-to-test classes that are 100% covered.

How to Fix:

Write more unit-tests for uncovered code. Hard-to-test code signals a design needing refactoring. For code impossible to cover (like MessageBox.Show()), define an infrastructure to mock it at test-time.

Constant 10 minutes Debt: the testing effort is already estimated by the Code Coverage rules. But severity is High, higher for new types: the time to write tests is now, before the next production release.

From now, all methods added should respect basic quality principles

Runs only in diff mode (baseline defined), on methods added since baseline (easily modified to also match refactored methods).

Matched methods violate basic quality principles: too large, too complex (many if, switch case, loops…), too many variables, parameters or overloads.

How to Fix:

Split the method into smaller methods or even new classes. Question each local variable's scope: it may become an instance field of the new class(es). Large switch…case can become types implementing a common interface, polymorphism replacing the switch cases tests. Write tests for each method before extracting it.

Constant 5 minutes Debt: the fix effort is already estimated by the Code Smells rules. But severity is High, higher for new methods: the time to improve them is now, before the next production release.

Avoid decreasing code coverage by tests of types

Runs only in diff mode (baseline defined) and when coverage data is imported. Warns when a type's covered lines decreased since baseline (for refactored types, accounting for lines of code added).

This can mean tests were removed, but more often that changes haven't been properly covered by tests.

To visualize changes, right-click a matched type and select:

- Compare older and newer versions of source file

- or Compare older and newer versions decompiled with Reflector

How to Fix:

Write more unit-tests covering the changes. Hard-to-test code signals a design needing refactoring.

Estimated Debt: linear from 15 minutes to 3 hours with the number of lines no longer covered. Severity varies from High to Critical likewise: fix these issues now, before such code gets released in production.

Avoid making complex methods even more complex

Runs only in diff mode (baseline defined). Warns when an already complex method (Cyclomatic Complexity > 6) became even more complex since baseline. Metric: https://www.ndepend.com/docs/code-metrics#CC

Requires PDB files and source code at analysis time. See: https://www.ndepend.com/docs/ndepend-analysis-inputs-explanation

To visualize changes, right-click a matched method and select:

- Compare older and newer versions of source file

- or Compare older and newer versions decompiled with Reflector

How to Fix:

Split into smaller methods or even new classes. Question each local variable's scope: it may become an instance field of the new class(es). Large switch…case can become types implementing a common interface, polymorphism replacing the switch cases tests. Write tests for each method before extracting it.

Estimated Debt: linear from 15 to 60 minutes with the extra complexity. Severity is High: fix these issues now, before such code gets released in production.

Avoid making large methods even larger

Runs only in diff mode (baseline defined). Warns when an already large method (more than 15 lines of code) became even larger since baseline. Metric: https://www.ndepend.com/docs/code-metrics#NbLinesOfCode

Requires PDB files at analysis time. See: https://www.ndepend.com/docs/ndepend-analysis-inputs-explanation

To visualize changes, right-click a matched method and select:

- Compare older and newer versions of source file

- or Compare older and newer versions decompiled with Reflector

How to Fix:

Usually split too big methods into smaller ones. But long branch-free methods (typically data initialization) are not necessarily a problem.

Estimated Debt: linear from 10 to 60 minutes with the lines of code added. Severity is High: fix these issues now, before such code gets released in production.

Avoid adding methods to a type that already had many methods

Runs only in diff mode (baseline defined). Lists types that already had more than 40 methods at baseline and got new ones. Such types are hard to maintain, symptom of too many responsibilities. Constructors and compiler-generated methods are not counted.

How to Fix:

Split the type into smaller types implementing the same logic together.

Estimated Debt: 10 minutes per method added. Severity is High: fix these issues now, before such code gets released in production.

Avoid adding instance fields to a type that already had many instance fields

Runs only in diff mode (baseline defined). Lists types that already had more than 15 fields at baseline and got new ones. Such types are hard to maintain, symptom of too many responsibilities. Constants, static-readonly fields and enumerations are not counted.

How to Fix:

Group subsets of fields into smaller types and dispatch the methods logic into them.

Estimated Debt: 10 minutes per field added. Severity is High: fix these issues now, before such code gets released in production.

Avoid transforming an immutable type into a mutable one

Runs only in diff mode (baseline defined). Warns when an immutable type (instance fields unmodifiable after construction) became mutable.

Immutable instances can be used concurrently without synchronization, so users often rely on immutability; breaking it may break their code.

How to Fix:

If immutability matters for the matched type, refactor to preserve it.

Estimated Debt: 10 minutes plus 10 minutes per instance field now mutable. Severity is High: fix these issues now, before such code gets released in production.

Avoid interfaces too big

Matches interfaces with more than 14 methods, properties or events (a property or event counts as one member). Interfaces should have a single responsibility; overly large ones have too many.

The Interface Segregation Principle (ISP) warns that a large interface used by consumers each needing only specific methods couples those consumers unnecessarily. Large interfaces also lead to larger classes handling too many unrelated tasks.

How to Fix:

Refactor into smaller single-responsibility interfaces, e.g. split IFoo handling read and write into IFooReader and IFooWriter. A large public interface with many clients may make splitting impactful or unfeasible.

Estimated Debt: linear from 20 minutes (10 methods) to 7 hours (100+), halved if the interface is not publicly visible (only the current project is impacted).

Base class should not use derivatives

The open/closed principle states: software entities should be open for extension, but closed for modification. http://en.wikipedia.org/wiki/Open/closed_principle

Creating or modifying a derived class shouldn't require modifying the base class. A base class using its derivatives likely will, making extension no longer simple: bad design.

No warning when the derived class used is nested private in the base class (an encapsulated implementation detail).

How to Fix:

Understand the need for using derivatives, imagine a new design, refactor. Typically, encapsulate base-class access to derived classes behind an abstract or virtual method. Conditions on typeof(DerivedClass) need urgent refactoring the same way. A base class creating derived instances calls for the factory method pattern http://en.wikipedia.org/wiki/Factory_method_pattern or the abstract factory pattern http://en.wikipedia.org/wiki/Abstract_factory_pattern

Estimated Debt: 3 minutes per derived class used + 3 minutes per derived class member used.

Class shouldn't be too deep in inheritance tree

Warns about classes with 4 or more base classes (third-party base classes not counted: this rule is about your design).

In theory a well-thought long inheritance chain is fine; in practice it is more often a sign of confused design, hard to work with and maintain.

How to Fix:

Favor Composition over Inheritance: a derived class is bound to the base class implementation, and inheritance breaks encapsulation. Composition binds to interfaces instead, preserving encapsulation with a clearer, less coupled design — a powerful way to break a long inheritance chain. See: http://en.wikipedia.org/wiki/Composition_over_inheritance and http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance

Estimated Debt: linear in the depth of inheritance.

Class with no descendant should be sealed if possible

A non-static class not declared sealed can be subclassed wherever visible. Being a base class requires significant design effort; subclassing a class not designed for it leads to unanticipated issues. Most classes are non-sealed by neglect, not intention.

sealed brings performance gains (benchmark: https://www.meziantou.net/performance-benefits-of-sealed-class.htm) but its real benefit is to express the intention: not designed to be a base class, subclassing not allowed.

Public classes are not matched by default (they may be subclassed by library consumers); for an application, uncomment !t.IsPubliclyVisible.

How to Fix:

Assess whether each matched class is really meant to be subclassed; most will end up declared sealed.

Overrides of Method() should call base.Method()

Overrides should refine or complete the base method behavior; not calling the base method replaces it instead. Violations signal a design flaw, especially when the design justifies replacing rather than refining.

How to Fix:

Investigate whether inheritance is the right choice, or whether exposing the method polymorphically through an interface would be better. The template method pattern http://en.wikipedia.org/wiki/Template_method_pattern might help.

Do not hide base class methods

Method hiding: a base class defines non-virtual M() and a derived class also defines M() with the same signature, so base.M() and derived.M() behave differently — not polymorphism, where both invoke the same implementation on a derived instance. This leads to confusion; this rule warns about all such cases.

How to Fix:

Remove or rename the method, or change its parameter signature so it no longer hides the base method. Legitimate hiding (same name, different behavior) is very rare, see: https://learn.microsoft.com/en-us/archive/blogs/ericlippert/method-hiding-apologia

A stateless class or structure might be turned into a static type

Matches non-static, non-generic classes/structures with no instance fields, no interface implemented and no base class (other than System.Object): a stateless collection of pure functions, better hosted in a static class so clients needn't create an object.

How to Fix:

Declare all methods static and make the class/structure static. Severity is Low: more an advice than a problem.

Non-static classes should be instantiated or turned to static

A class whose constructors are never called is never instantiated and should be declared static.

Instantiation through reflection is not detected, so plug-in root classes instantiated via IoC frameworks can be false positives. Classes instantiated by ASP.NET infrastructure, view models and Entity Framework ModelSnapshot/DbContext/Migration classes are skipped. So are classes deriving from a third-party abstract class (an endpoint, a hosted service), and classes whose instance members are used by another type: a request DTO or a JSON response, created by a model binder or a serializer. Public classes are matched by default; for a framework whose clients instantiate them, uncomment !t.IsPublic.

How to Fix:

Investigate why the class is never instantiated. If it hosts only static methods, declare it static. If it is instantiated via reflection or by client code, adapt this rule to avoid these matches.

Methods should be declared static if possible

An instance method that can be safely declared static should be. The narrower a method's scope, the fewer bugs: static methods can't access instance members, the compiler enforces it, and the signature tells clients the call can't alter object state. It is also a micro performance optimization (no this reference passed).

Beware: declaring a designer-bound event handler static might break the designer generated code if it uses this.Method() syntax.

How to Fix:

Declare matched methods static; consider moving them to a static utility class since they use no instance member of their type or base-types.

Constructor should not call a virtual method

Matches constructors of a non-sealed class calling virtual methods.

Constructors run base-first, but virtual calls always execute on the most derived type. A virtual call in a constructor may thus run on a class whose constructor hasn't executed yet — an unsuitable state — making the class error-prone to derive from.

How to Fix:

Re-design object initialization or declare the class sealed if possible. A constructor should initialize its own class's state; extra setup belongs in derived constructors or methods called after construction.

Avoid the Singleton pattern

The singleton pattern ensures a class has only one runtime instance: http://en.wikipedia.org/wiki/Singleton_pattern

Avoid singletons: they make code less testable (the same instance is forced across unit tests) and harder to maintain (the static Instance getter gives uncontrolled access to shared state, degrading the code over time). Only singletons with mutable instance fields are matched, since the pitfalls come from unregulated access to instance data. More details: https://blog.ndepend.com/the-proper-usages-of-the-keyword-static-in-c/

How to Fix:

The problem is the usual singleton syntax (a static field holding the instance), which hinders testability — not having a single runtime instance. Create the instance at program startup and pass it explicitly to all classes and methods needing it. With multiple singletons, consider consolidating them into a single execution context, easier to propagate.

Estimated Debt: 3 minutes per method relying on the singleton — often hundreds of methods, hence hours of refactoring. Severity is Critical because a singleton can prevent the whole program from being testable and maintained.

Don't assign static fields from instance methods

Assigning static fields from instance methods leads to poorly maintainable and non-thread-safe code. More discussion: https://blog.ndepend.com/the-proper-usages-of-the-keyword-static-in-c/

How to Fix:

If the static field is assigned once per program lifetime, declare it readonly and assign it inline or in the static constructor. Otherwise hold mutable state in instance fields, the natural OOP artifact for it.

Avoid empty interfaces

An empty interface defines no members, hence no contract to implement. It is probably used as a marker to identify a group of types: for run-time identification use a custom attribute instead; for compile-time identification an empty interface is acceptable.

An empty interface implementing at least one other interface is not matched: implementing it requires implementing sub-interfaces members.

How to Fix:

Remove the interface or add members. If used as a marker, replace it with a custom attribute.

Estimated Debt: 10 minutes to discard the interface plus 3 minutes per implementing type.

Avoid types initialization cycles

The class constructor (static constructor, cctor in IL) runs the first time a type is used; a static field inline initialization is enough to declare it implicitly.

If the cctor of t1 uses t2 and vice-versa (cycles can span N types), unexpected hard-to-diagnose initialization bugs can occur. More: http://codeblog.jonskeet.uk/2012/04/07/type-initializer-circular-dependencies/

This rule enumerates such cycles. Lambdas defined in cctors (or methods they call) are considered executed at initialization time, which may cause false positives.

How to Fix:

If several states held by several classes must be initialized on first access of any of them, create a dedicated class that initializes and holds all these states.

Estimated Debt: 20 minutes per cycle plus 10 minutes per class constructor involved.

Avoid custom delegates

Prefer generic delegates over custom delegates:

- Action<…> for void return type.

- Func<…> for a return type (last generic argument).

- Predicate<T> for a T instance returning a boolean.

- Expression<…> for function definitions compiled/invoked at runtime, also serializable to remote processes.

They clarify code and remove delegate type maintenance. Do not convert delegates consumed by DllImport extern methods (marshalling issues).

How to Fix:

Replace custom delegates with the generic delegates shown in the replaceWith column.

Estimated Debt: 5 minutes per custom delegate plus 3 minutes per method using it.

Types with disposable instance fields must be disposable

Warns when a class has an instance field whose type implements System.IDisposable or System.IAsyncDisposable but does not implement IDisposable itself: such a class indirectly owns an unmanaged resource. If it owns no unmanaged resource directly, it should not have a finalizer.

False positives can occur when the referenced disposable objects outlive the referencing object.

How to Fix:

Implement IDisposable and call the fields' Dispose() from IDisposable.Dispose(). Then ensure every method calling a constructor of the type disposes the objects created.

Estimated Debt: 5 minutes per type plus 2 minutes per disposable field plus 4 minutes per method calling a constructor.

Disposable types with unmanaged resources should declare finalizer

Reports disposable types (System.IDisposable / IAsyncDisposable) with no finalizer (Object.Finalize()) that contain fields suggesting unmanaged resources:

- System.IntPtr

- System.UIntPtr

- System.Runtime.InteropServices.HandleRef

Disabled by default: it typically reports false positives for classes merely referencing managed resources without the responsibility to dispose them. Uncomment warnif count > 0 to enable.

How to Fix:

Implement a finalizer that calls your Dispose() method.

Methods that create disposable object(s) and that don't call Dispose()

Enumerates methods creating disposable object(s) without calling any Dispose() method. Not a rule: this is acceptable when the objects are disposed elsewhere. Easily refactored to target specific disposable types or caller methods, and turned into a rule.

Disposable Types Must Unsubscribe Events

Detects disposable types subscribing to events in constructors without unsubscribing in Dispose() (or a method it calls). Event publisher references can keep instances alive: memory leaks, unexpected callbacks.

How to Fix:

1) Match each constructor subscription with an unsubscription in Dispose() (or a method always called by it). 2) Centralize subscriptions/unsubscriptions in dedicated methods for explicit symmetry. 3) With inheritance, follow the full dispose pattern so derived types can release additional subscriptions. 4) Prefer weak-event patterns or explicit lifetime ownership when the publisher outlives the subscriber.

Classes that are candidate to be turned into structures

Structures suit lightweight values (like Int32 or Boolean): as values, they are not managed by the garbage collector, cheaper for plenty of short lived instances. This rule matches classes looking like lightweight values:

- It has instance fields, all typed with value-types.

- It is immutable.

- It implements no interfaces.

- It has no parameterless constructor, is not generic.

- It has no derived classes and derives directly from System.Object.

- Not an ASP.NETCore ViewModel (name ending with Model) or Repository.

Whether instances are numerous short-lived objects is not checked: these criteria are indications, only you can decide if the change is performance wise.

How to Fix:

Use the keyword struct instead of class.

CAUTION: first understand the deep implications explained here: https://blog.ndepend.com/class-vs-struct-in-c-making-informed-choices/

Estimated Debt: 5 minutes per class plus 1 minute per method using it.

Avoid namespaces with few types

Warns about non-global namespaces containing fewer than five types. Numerous sparsely populated namespaces require many using clauses in client code. Namespaces should group types used together (separate ones for mutually exclusive uses) and organize features for discoverability.

The rule source contains a completable list of common infrastructure namespace names; namespaces ending with these names are not matched.

How to Fix:

Combine namespaces containing just a few types into a single namespace.

Nested types should not be visible

Warns about nested types not declared private. Nested types serve to encapsulate private implementation details of the containing type and should not be externally visible. Do not use them for logical grouping or name collision avoidance — use namespaces. Protected nested types can be used in subclasses.

How to Fix:

Change the type's accessibility if it needn't be externally visible; otherwise make it non-nested. For grouping, use a namespace instead.

Estimated Debt: 2 minutes per nested type plus 4 minutes per outer type using it.

Declare types in namespaces

Types outside any named namespace live in the global namespace (the anonymous namespace), which cannot be referenced in code: naming collisions, ambiguity, and no encapsulation of related code and data. This rule warns about anonymous namespaces.

How to Fix:

Declare all types of anonymous namespaces in named namespaces.

Empty static constructor can be discarded

Warns about static constructors (cctor in IL, run by the CLR before the type's first use) containing no lines of code: useless, safely removable.

How to Fix:

Remove matched empty static constructors.

Instances size shouldn't be too big

Types where SizeOfInst > 128 might degrade performance if many instances are created, and can be hard to maintain. A large SizeOfInst may come from a base class rather than many own fields.

WPF/WindowsForm forms and controls, Entity Framework classes, and base classes implying large instances (System.ComponentModel, System.Xml, DevExpress…) are not matched; add other vendors as needed. SizeOfInst metric: https://www.ndepend.com/docs/code-metrics#SizeOfInst

How to Fix:

Group the data held directly into smaller composable types.

Severity: linear from Medium (128 bytes) to twice High (2048 bytes) per instance. Annual interest is 10x higher for structures: each time a large structure value is passed as parameter it gets copied, so such a structure should be declared as class.

Attribute classes should be sealed

.NET methods fetching custom attributes (like System.Attribute.GetCustomAttribute()) explore the attribute inheritance hierarchy by default. Sealing the attribute removes that search, potentially enhancing performance.

How to Fix:

Seal the attribute type or make it abstract.

Don't use obsolete types, methods or fields

Warns about methods using a type, method or field tagged with System.ObsoleteAttribute: such API elements will be removed sooner or later and shouldn't be used.

How to Fix:

Follow the workaround message typically provided with System.ObsoleteAttribute to avoid the obsolete element.

Estimated Debt: 5 minutes per type, method or field used. Severity is High: it is important to no longer rely on obsolete code.

Do implement methods that throw NotImplementedException

Warns about methods using NotImplementedException: a temporary facility to declare a method stub deferring implementation (useful in TDD where tests fail until implemented). Before releasing, it shouldn't be used anywhere.

Don't use it permanently to mean this method should be overriden or this facility is unsupported — use abstract methods/classes instead, favoring compile time errors over run-time errors.

How to Fix:

Investigate why NotImplementedException is still thrown.

Severity is High if the method only throws it: the method should be implemented, is bad run-time-error-by-design, or is a removable stub. Severity is Medium if thrown from a method with significant logic: often the fix is throwing another type like InvalidOperationException.

Override equals and operator equals on value types

For value types, the inherited Equals() uses Reflection (expensive) and compares all instance fields (often unnecessary). If instances get compared, sorted or used as hash table keys, implement Equals(), GetHashCode() and the equality/inequality operators.

How to Fix:

Implement Equals(), GetHashCode() and the equality and inequality operators, or transform the type into a record struct.

Estimated Debt: 15 minutes plus 2 minutes per instance field.

Boxing/unboxing should be avoided

Boxing wraps a value type inside a System.Object on the managed heap (implicit); unboxing extracts it (explicit). More: https://msdn.microsoft.com/en-us/library/yz2be5wk.aspx

Disabled by default to avoid noise; re-activate if boxing/unboxing matters to your team.

How to Fix:

With .NET generics (especially generic collections), boxing/unboxing is rarely needed and can usually be refactored away. See: http://stackoverflow.com/questions/4403055/boxing-unboxing-and-generics

Profile for CPU-heavy methods using boxing/unboxing, especially in a loop, and refactor them. Severity is Low: more an advice than a problem.

Avoid namespaces mutually dependent

Lists types and methods from a low-level namespace that use types and methods from a higher-level namespace, for each pair of namespaces using each other. Which is low-level is inferred by comparing the couplings [A to B] and [B to A] (types, methods and fields involved): the low-to-high coupling is typically the significantly lower one. Dependencies on the compiler's synthesized types of the global namespace (anonymous types, collection-expression lists) are ignored.

This avoids namespaces dependency cycles, moving toward a layered architecture where low-level code cannot use high-level code — i.e. getting rid of spaghetti code: entangled code not properly layered and structured. More in our white books: https://www.ndepend.com/docs/white-books

How to Fix:

Refactor so that the low-level namespace doesn't use the high-level namespace. The rule lists each culprit dependency; patterns to remove them:

- Move types between the low-level and high-level namespaces.

- Use the Dependency Inversion Principle (DIP): https://blog.ndepend.com/solid-design-the-dependency-inversion-principle-dip Create interfaces in the low-level namespace, implemented in the high-level one, so low-level code consumes high-level code through interfaces (callbacks), passed in via higher-level code — a.k.a. Dependency Injection (DI): http://en.wikipedia.org/wiki/Dependency_injection

May not apply to libraries with public mutually dependent namespaces, where breaking the API can cost more than the entangled code.

Debt depends on the number of types and methods used. Both namespaces form an unpartitionable super-component, so Annual Interest is one hour plus minutes proportional to their size in lines of code, divided by the number of issues listed. It often exceeds the Debt: a year unfixed costs more than fixing once.

Avoid namespaces dependency cycles

Lists all application namespace dependency cycles; each row shows a cycle indexed with one entangled namespace. Avoiding cycles is a simple yet efficient way to clean a code base architecture; see our white books: https://www.ndepend.com/docs/white-books

How to Fix:

First fix the rule Avoid namespaces mutually dependent: this eliminates most cycles. Remaining cycles involve 3+ namespaces, like A is using B is using C is using A.

Right-click a cycle cell to export the namespaces to the dependency graph or matrix, illustrated here: https://www.ndepend.com/docs/visual-studio-dependency-graph#Entangled Then decide which namespaces are low-level vs high-level and remove the offending dependencies (e.g. if A is low-level, C shouldn't use A), using the patterns in Avoid namespaces mutually dependent HowToFix.

The matrix shows cycles as red squares and black cells; use the option Display Direct and Indirect Dependencies. See: https://www.ndepend.com/docs/dependency-structure-matrix-dsm#Cycle https://www.ndepend.com/docs/dependency-structure-matrix-dsm#Mutual

Estimated Debt doesn't depend on cycle length: even a long cycle can be broken by removing a few dependencies.

Avoid partitioning the code base through many small library Assemblies

Matches assemblies with 3 or fewer types. Each assembly is a DLL and a project to maintain; too many is a symptom of treating physical projects as logical components. Prefer fewer, bigger projects with namespaces as logical components: faster compilation and startup, clearer Solution Explorer, easier deployment, fewer assemblies for library clients.

How to Fix:

Use the physical concept of assemblies for physical needs only. Our white book Partitioning code base through .NET assemblies and Visual Studio projects details valid and invalid reasons: https://www.ndepend.com/Res/NDependWhiteBook_Assembly.pdf

Enforcing Clean Architecture

Ensures strict inward dependency flow between layers: only Presentation -> Application -> Domain. Flags outward or sideways dependencies (e.g. Domain -> Infrastructure).

How to Fix:

1) Move business rules used by multiple layers into Domain or Application. 2) Replace direct references to outer layers with abstractions defined in an inner layer. 3) Implement those abstractions in Infrastructure/Presentation, injected from the composition root. 4) Move DTOs/view models to their boundary layer; map at boundaries instead of sharing concrete outer-layer types.

UI layer shouldn't use directly DB types

A sample rule to adapt to your need showing how to define code layers and be warned about dependency violations. It checks if any UI layer type directly uses any DB framework layer type.

- DB framework layer: third-party types of ADO.NET, EntityFramework, NHibernate consumed by the application (easy to adjust).

- UI layer: types using WPF, Windows Form, ASP.NET.

UI using directly DB frameworks is poor design: DB accesses should be hidden from UI in a dedicated Data Access Layer (DAL). Estimated debt is proportional to the UI/DB coupling.

How to Fix:

The rule lists which UI type uses which DB framework type. Rather than fixing matches one by one, first imagine how DB framework accesses could be encapsulated into a dedicated layer.

UI layer shouldn't use directly DAL layer

A sample rule to adapt to your need showing how to define code layers and be warned about dependency violations. It checks if any UI layer type directly uses any DAL layer type.

- DAL (Data Access Layer): application types using ADO.NET, EntityFramework, NHibernate types (easy to adjust).

- UI layer: types using WPF, Windows Form, ASP.NET.

UI using directly DAL is poor design: DAL accesses should be hidden from UI in an intermediary domain logic. Estimated debt is proportional to the UI/DAL coupling.

How to Fix:

The rule lists which UI type uses which DAL type. More on this topic: http://www.kenneth-truyers.net/2013/05/12/the-n-layer-myth-and-basic-dependency-injection/

Assemblies with poor cohesion (RelationalCohesion)

Warns about assemblies with a wrong Relational Cohesion: the number of relationships between the assembly's types divided by the number of types (average types used per type). Classes inside an assembly should be strongly related, so cohesion should be high. Assemblies with fewer than 20 types are ignored.

How to Fix:

Matches reveal either specific coding constraints (like generated code) or design issues; in the latter case plan refactoring to increase overall design and maintainability.

Severity is Low: Relational Cohesion informs about code structure but is not actionable. Fixing actionable Architecture and Code Smells issues will necessarily increase the scores.

Namespaces with poor cohesion (RelationalCohesion)

Warns about namespaces with a wrong Relational Cohesion: the number of relationships between the namespace's types divided by the number of types (average types used per type). Classes inside a namespace should be strongly related, so cohesion should be high. Namespaces with fewer than 20 types are ignored.

How to Fix:

Matches reveal either specific coding constraints (like generated code) or design issues; in the latter case plan refactoring sessions. Right-click the ChildTypes cells to export them to the graph and get a class coupling overview.

Severity is Low: Relational Cohesion informs about code structure but is not actionable. Fixing actionable Architecture and Code Smells issues will necessarily increase the scores.

Assemblies that don't satisfy the Abstractness/Instability principle

The Abstractness versus Instability Diagram identifies assemblies potentially painful to maintain (concrete and stable) and potentially useless (abstract and instable).

- Abstractness: many abstract types (interfaces, abstract classes), few concrete ones.

- Stability: types used by many types from other assemblies (painful to modify).

The normalized distance ([0.0 … 1.0]) from the idealized line A + I = 1 (main sequence) indicates the abstractness/stability balance; this rule warns above 0.7. Metric explained here: https://www.ndepend.com/docs/code-metrics#DitFromMainSeq Concepts introduced by Robert C. Martin in 1994: http://www.objectmentor.com/resources/articles/oodmetrc.pdf

How to Fix:

The assembly is either potentially painful to maintain (massively used, mostly concrete: create abstractions to reduce coupling with concrete implementations) or potentially useless (mostly abstract, not used enough: review the design).

Severity is Low: this principle informs about code structure but is not actionable. Fixing actionable Architecture and Code Smells issues will push the scores in the right direction.

Avoid excessive class coupling

Assesses class coupling for types and methods by counting the unique application types consumed and their namespaces. High coupling suggests too many responsibilities, violating the Single Responsibility Principle: https://blog.ndepend.com/solid-design-the-single-responsibility-principle-srp/

How to Fix:

Break the type or method into smaller, more focused components each following a single responsibility.

Higher cohesion - lower coupling

Good architecture separates abstract namespaces (only interfaces, enumerations, delegates) from concrete ones (classes, structures). The more concrete namespaces rely only on abstract ones, the more Decoupled the architecture and the more Cohesive the classes.

This query shows, for each concrete namespace, which concrete and abstract namespaces are used.

How to Fix:

Transform this query into a rule if you wish to constrain your coupling / cohesion ratio.

Avoid mutually-dependent types

Matches pairs of classes or structures using each other: neither can be reviewed, refactored or tested without the other.

Disabled by default: mutual dependency is legitimate in common situations like recursive data structures, complex serialization or the visitor pattern. Enable it if you wish to fix most of its issues.

How to Fix:

Identify the unwanted dependency (t1 using t2, or the reverse) and remove it, often via the dependency inversion principle — interfaces abstracting one implementation from the other: https://blog.ndepend.com/solid-design-the-dependency-inversion-principle-dip

Example of custom rule to check for dependency

A sample rule showing how to check if a dependency exists from a code element A to B (each being an Assembly, Namespace, Type, Method or Field, not necessarily of the same kind).

Generate such a rule by right-clicking the Dependency Matrix cell (B in row, A in column) or the Dependency Graph arrow from A to B, then clicking Generate a code rule that warns if this dependency exists. Adapt the generated rule to your needs.

How to Fix:

This is a sample rule, there is nothing to fix as is.

API Breaking Changes: Types

Runs only in diff mode (baseline defined). Warns if a type publicly visible in the baseline is no longer public or has been removed: client code using it will be broken.

How to Fix:

Keep public types public, now and in the future. If a public type must be removed, tag it with System.ObsoleteAttribute and a workaround message for a few releases first (obsolete-tagged removals are not matched).

Severity is High: an API Breaking change can provoke significant friction with API consumers.

API Breaking Changes: Methods

Runs only in diff mode (baseline defined). Warns if a method publicly visible in the baseline is no longer public or has been removed: client code using it will be broken.

How to Fix:

Keep public methods public, now and in the future. If a public method must be removed, tag it with System.ObsoleteAttribute and a workaround message for a few releases first (obsolete-tagged removals are not matched).

Severity is High: an API Breaking change can provoke significant friction with API consumers.

API Breaking Changes: Fields

Runs only in diff mode (baseline defined). Warns if a field publicly visible in the baseline is no longer public or has been removed: client code using it will be broken.

How to Fix:

Keep public fields public, now and in the future. If a public field must be removed, tag it with System.ObsoleteAttribute and a workaround message for a few releases first (obsolete-tagged removals are not matched).

Severity is High: an API Breaking change can provoke significant friction with API consumers.

API Breaking Changes: Interfaces and Abstract Classes

Runs only in diff mode (baseline defined). Warns if a publicly visible interface or abstract class got abstract methods added or removed: client code implementing or deriving from it will be broken.

How to Fix:

Keep public contracts of interfaces and abstract classes stable, now and in the future. If a contract must change, tag abstract methods to be removed with System.ObsoleteAttribute and a workaround message for a few releases first.

Severity is High (not Critical, since an interface is not necessarily meant to be implemented by API consumers).

Broken serializable types

Runs only in diff mode (baseline defined). Warns about types tagged SerializableAttribute whose serializable instance fields were added or removed (fields tagged NonSerializedAttribute are ignored).

From http://msdn.microsoft.com/library/system.serializableattribute.aspx : all fields of a SerializableAttribute type are serialized by default, unless the type implements ISerializable or fields are marked NonSerializedAttribute.

How to Fix:

Keep the serialization process of serializable types stable, now and in the future; else deal with Version Tolerant Serialization: https://msdn.microsoft.com/en-us/library/ms229752(v=vs.110).aspx

Severity is High: an API Breaking change can provoke significant friction with API consumers.

Avoid changing enumerations Flags status

Runs only in diff mode (baseline defined). Matches enumerations whose FlagsAttribute tagging changed since the baseline (added or removed).

FlagsAttribute is a strong property, less for behavior (only enum.ToString() changes) than for meaning: range of values or range of flags? Changing it can significantly impact clients.

How to Fix:

Keep the FlagsAttribute status of each enumeration stable, now and in the future.

API: New publicly visible types

Runs only in diff mode (baseline defined). Lists types new in the public surface of the analyzed assemblies.

API: New publicly visible methods

Runs only in diff mode (baseline defined). Lists methods new in the public surface of the analyzed assemblies.

API: New publicly visible fields

Runs only in diff mode (baseline defined). Lists fields new in the public surface of the analyzed assemblies.

Code should be tested

Lists the methods not covered or partially covered by tests, one issue per method — also in a type no test reaches yet: writing the first tests of a type fixes issues, it never turns one issue into several.

The technical debt (effort to write tests) is the effort to develop the code element multiplied by factors in ]0,1.3] based on:

- the method code size and complexity

- the actual percentage coverage

- the abstractness of types used (classes are harder to test than interfaces)

- the method visibility (private/protected harder to test)

- reads of mutable static fields (state shared across tests executions)

- JustMyCode or not (NotMyCode is often generated, with generatable tests)

This rule is a large debt source: untested code is by definition part of the technical debt. The annual interest (annual cost of leaving code uncovered) is based on the effort to develop times usage factors.

The Testability column (0 to 100, higher = easier to unit test) and the TestHurdle column help to pick the quick wins first. Testability decreases with the number of methods called (the strongest sign), with a hurdle reached (hard: a process, the network, a database or console key input, up to 3 calls deep; soft: the file system, HttpClient, the environment, a sleep or console line input, called directly), with the method complexity, when tests cannot call the method (private, or internal without InternalsVisibleTo) and when no test reaches its type yet; it increases for a static method without mutable state. TestHurdle names the hurdle reached and, deeper than one call, the first call of the chain.

How to Fix:

Write unit tests covering the matched methods.

New Types and Methods should be tested

Runs only in diff mode (baseline defined) and when coverage data is imported, on types and methods added since baseline.

Covered code is maintainable and non-error-prone. Since stopping development to test a poorly covered code base is impracticable, each time a method or type gets added, write associated unit-tests. Maintainability increases, refactoring becomes driven by testability, and the overall design improves.

Severity is High: these issues reflect an actual trend of not writing tests for new code.

How to Fix:

Write unit-tests covering most methods and types added since the baseline.

Methods refactored should be tested

Runs only in diff mode (baseline defined) and when coverage data is imported, on methods refactored since baseline.

Covered code is maintainable and non-error-prone. Since stopping development to test a poorly covered code base is impracticable, each time a method or type gets refactored, write associated unit-tests. Maintainability increases, refactoring becomes driven by testability, and the overall design improves.

Severity is High: these issues reflect an actual trend of not writing tests for refactored code.

How to Fix:

Write unit-tests covering most refactored methods and classes.

Assemblies and Namespaces should be tested

Lists assemblies and namespaces not covered at all by unit tests (a matched assembly's children namespaces are not matched).

Its goal is to inform of large untested code elements — not to collide with Code should be tested, which details uncovered code, Debt and Annual Interest per method. Hence Debt is only 4 minutes per issue and severity is Low.

How to Fix:

Write unit and integration tests to cover, even partially, the matched elements. Then use Code should be tested, New Types and Methods should be tested and Methods refactored should be tested to write tests where they matter most, refactoring for testability if needed.

Types almost 100% tested should be 100% tested

Runs only when coverage data is imported.

Covering the last few percents of a class is as hard as the first 90%, so teams often settle for 90%. But untestable code usually means poorly written, error prone code: worth covering because most tricky bugs might come from this small portion of hard-to-test code. Not all classes need 100% coverage (e.g. UI), but most of the application logic should live in easy-to-test classes 100% covered.

Severity is High: such situation is bug-prone.

How to Fix:

Write more unit-tests for uncovered code. Hard-to-test code signals a design needing refactoring.

Namespaces almost 100% tested should be 100% tested

Runs only when coverage data is imported.

Covering the last few percents of a namespace's classes is as hard as the first 90%, so teams often settle for 90%. But untestable code usually means poorly written, error prone code: worth covering because most tricky bugs might come from this small portion of hard-to-test code. Not all classes need 100% coverage (e.g. UI), but most of the application logic should live in easy-to-test classes 100% covered.

Severity is High: such situation is bug-prone.

How to Fix:

Write more unit-tests for uncovered code in the namespace. Hard-to-test code signals a design needing refactoring.

Types that used to be 100% covered by tests should still be 100% covered

Runs only in diff mode (baseline defined) and when coverage data is imported. Warns when a type fully covered by tests in the baseline is now only partially covered.

The last ~10% of a class is as hard to cover as the first 90%, but untestable code usually means poorly written, error prone code: most tricky bugs might come from this small portion of hard-to-test code. Most application logic should live in easy-to-test classes 100% covered.

Severity is High: a type that lost 100% coverage is a bug-prone situation to handle carefully.

How to Fix:

Write more unit-tests for code no longer covered. Hard-to-test code signals a design needing refactoring. For code impossible to cover (like MessageBox.Show()), define an infrastructure to mock it at test-time.

Types tagged with FullCoveredAttribute should be 100% covered

Lists partially covered methods of types tagged FullCoveredAttribute. Runs only when coverage data is imported.

FullCoveredAttribute expresses in source code the intention that a class is and should remain 100% covered — an intention continuously checked by this rule. To avoid linking NDepend.API.dll, use your own attribute and adapt the rule.

The last ~10% of a class is as hard to cover as the first 90%, but untestable code usually means poorly written, error prone code: most tricky bugs might come from this small portion of hard-to-test code.

Severity is High: a type that lost 100% coverage is a bug-prone situation to handle carefully.

How to Fix:

Write more unit-tests for uncovered code of matched classes. Hard-to-test code signals a design needing refactoring.

Types 100% covered should be tagged with FullCoveredAttribute

Runs only when coverage data is imported.

An attribute class named FullCoveredAttribute expresses in source code the intention that a class is and should remain 100% covered — an intention continuously checked by the rule Types tagged with FullCoveredAttribute should be 100% covered.

Severity is Low: an advice for improvement, not a problem.

How to Fix:

Tag 100% covered types with the FullCoveredAttribute class from NDepend.API.dll, or your own attribute with this name in any namespace.

Methods should have a low C.R.A.P score

Runs only when coverage data is imported.

Change Risk Analyzer and Predictor (CRAP) pinpoints code both complex and untested. First defined here: http://www.artima.com/weblogs/viewpost.jsp?thread=215899

Formula: CRAP(m) = CC(m)^2 * (1 – cov(m)/100)^3 + CC(m), where CC(m) is the cyclomatic complexity and cov(m) the percentage coverage.

Matched methods cumulate two error prone smells: complexity (hard to maintain) and incomplete coverage (hard to refactor without regression). The threshold of 30 is the one suggested by the inventors; no amount of testing keeps methods with CC > 30 out of CRAP territory. Methods with fewer than 10 lines of code are not matched.

How to Fix:

Refactor the complex logic into smaller, less complex methods (possibly in new types) and write unit-tests to fully cover it. For code impossible to cover (like MessageBox.Show()), define an infrastructure to mock it at test-time.

Complex Methods should be 100% tested

Detects methods with a low maintainability index and insufficient test coverage: hard to understand, error prone and risky to modify. Maintainability index definition: https://www.ndepend.com/docs/code-metrics#MaintainabilityIndex

How to Fix:

1. Break large or complex methods into smaller, focused units.

2. Improve readability: clear naming, consistent formatting, less nesting.

3. Write unit tests validating both common and edge cases.

4. Ensure refactored code is fully covered by tests before merging.

Test methods should assert something

Matches test methods (methods tagged with a test attribute like [Test], [Fact] or [TestMethod]) that call no assertion API, directly or through helper methods. Such a test covers code without checking what this code does: coverage figures overstate how well the code is tested.

Assertion APIs recognized: the Assert classes of NUnit, xUnit, MSTest and TUnit, FluentAssertions, Shouldly, NFluent, Verify, ApprovalTests, mock verifications (Moq Verify(), NSubstitute Received(), FakeItEasy MustHaveHappened()), BDD runners (SpecFlow, Reqnroll, LightBDD), Roslyn analyzer and code fix tests and any third-party method named Assert... or declared in a type named ...Assert.... Assert.Pass(), Assert.Ignore(), Assert.Inconclusive(), Assume, Warn and Debug.Assert() check nothing.

Not matched: tests whose returned value is checked by the test framework (NUnit ExpectedResult, FsCheck properties), tests tagged with [ExpectedException] and tests invoking a member dynamically (a call with a dynamic argument is bound at run-time and might assert).

Unlike other default rules, this rule reports issues on test code.

How to Fix:

Assert the observable outcome of the code exercised: returned values, state changes or expected interactions. A test meant to only check that no exception is thrown can say so, like with NUnit Assert.DoesNotThrow().

If your tests check through your own helpers that throw an exception instead of calling an assertion API, add these helpers to the list at the top of the rule source.

Debt is 5 minutes per test: understand what the test exercises and assert it.

Test Methods

Lists test methods: methods tagged with a test attribute of a supported test framework (xUnit, NUnit, MSTest, TUnit…) declared in test assemblies.

Test assemblies (assemblies referencing a test framework) belong to the TestCode view, disjoint from Application: rules don't report issues on test code (except Test methods should assert something), while dependencies between test and application code remain available, as in this query.

Methods directly called by test Methods

Lists all application methods directly called by test methods (methods of the TestCode view tagged with a test attribute). Not listed: overrides called through polymorphism, methods solely invoked through a delegate or through reflection.

Methods directly and indirectly called by test Methods

Lists all application methods directly or indirectly called by test methods (methods of the TestCode view tagged with a test attribute). The recursion yields the depthOfCalledByTests metric: 1 = directly called by a test, 2 = called by a method called by a test… Not listed: overrides called through polymorphism, methods solely invoked through a delegate or through reflection.

Potentially Dead Types

Lists potentially dead types: removable because never used by the program. It matches types not used anywhere and types used only by such types — hence the TypesUsingMe column and the depth metric (0 = not used, 1 = used only by unused types, etc…).

Public types are not matched by default (client code not analyzed by NDepend might use them); easily changed. Entity Framework ModelSnapshot classes (used only by the EF infrastructure) are not matched.

Usages from test code (the TestCode view) keep a type alive: a type used only from tests is not matched here but by the rule Code used only by tests, disabled by default.

How to Fix:

Static analysis cannot list dead types exactly: types can be used dynamically (like through reflection). Investigate each match; if truly unused, remove it to avoid maintaining useless code, or comment it out with a note on future intentions.

If a used type is still matched, tag it with IsNotDeadCodeAttribute from NDepend.API.dll (or your own attribute, adapting the rule).

Debt is 15 minutes (quick investigation). Annual Interest is proportional to the type's #lines of code: the bigger, the more it slows down maintenance.

Potentially Dead Methods

Lists potentially dead methods: removable because never called by the program. It matches methods not called anywhere and methods called only by such methods — hence the MethodsCallingMe column and the depth metric (0 = not called, 1 = called only by uncalled methods, etc…).

Public methods are not matched by default (client code not analyzed by NDepend might call them); easily changed.

Calls from test code (the TestCode view) keep a method alive: a method called only from tests is not matched here but by the rule Code used only by tests, disabled by default.

How to Fix:

Static analysis cannot list dead methods exactly: methods can be invoked dynamically (like through reflection). Investigate each match; if truly never invoked, remove it to avoid maintaining useless code, or comment it out with a note on future intentions.

If an invoked method is still matched, tag it with IsNotDeadCodeAttribute from NDepend.API.dll (or your own attribute, adapting the rule).

Debt is 10 minutes (quick investigation) plus 3 minutes per unit of depth: dead methods only called by dead code take longer to investigate. Annual Interest is proportional to the method's #lines of code: the bigger, the more it slows down maintenance.

Potentially Dead Fields

Lists potentially dead fields: removable because never used by the program.

Public fields are not matched by default (client code not analyzed by NDepend might use them); easily changed — rules in the Visibility group warn about public fields. Enumeration values and literal constants are also not matched: their usage is lost in the compiled IL code NDepend analyzes.

Usages from test code (the TestCode view) keep a field alive: a field used only from tests is not matched here but by the rule Code used only by tests, disabled by default.

How to Fix:

Static analysis cannot list dead fields exactly: fields can be read or assigned dynamically (like through reflection). Investigate each match; if truly unused, remove it to avoid maintaining a useless code element.

If a used field is still matched, tag it with IsNotDeadCodeAttribute from NDepend.API.dll (or your own attribute, adapting the rule).

Debt is 10 minutes (quick investigation); Annual Interest is 8 minutes per unused field matched.

Wrong usage of IsNotDeadCodeAttribute

NDepend.Attributes.IsNotDeadCodeAttribute (from NDepend.API.dll, replaceable by your own attribute) marks elements not used directly but used somehow (like through reflection), for the Potentially dead Types/Methods/Fields rules.

This rule matches elements tagged with this attribute that are nevertheless used directly somewhere in the code.

How to Fix:

Remove the now-useless IsNotDeadCodeAttribute tagging of matched elements.

Code used only by tests

Lists application types, methods and fields used only from test code (the TestCode view): the program itself never uses them, only tests keep them alive. The testUsers column lists these test code users.

Such code is either dead production code whose tests were left behind, or a test helper living in the application code.

When a type is matched, its members and nested types are not matched. Elements exempted by the Potentially Dead Types/Methods/Fields rules (public API, infrastructure entry points, IsNotDeadCodeAttribute…) are not matched either.

How to Fix:

If the element is dead production code, remove it together with the tests that exercise it.

If it is a test helper, move it into the test code: a method that only uses members visible from the tests can become an extension method there, so its call sites stay unchanged.

If it is a deliberate test hook, or is used in ways IL analysis cannot see, tag it with IsNotDeadCodeAttribute from NDepend.API.dll.

Debt is 25 minutes for a type, 20 for a method and 15 for a field: the tests must be updated too. Annual Interest is proportional to the #lines of code and divided by 4 (2 minutes for a field), since such code is still exercised by the tests.

Software Composition Analysis (SCA)

Raises an issue per consumed NuGet package version with known security advisories listed on GitHub: https://github.com/advisories?query=+ecosystem%3Anuget The issue is reported on the first type (alphabetically) using a third-party assembly from the affected package.

Flagged Code

<!-- MyApp.csproj: Newtonsoft.Json 12.0.1 has the advisory GHSA-5crp-9r3c-p9vr -->
<ItemGroup>
   <PackageReference Include="Newtonsoft.Json" Version="12.0.1" />
</ItemGroup>

<!-- 13.0.1 is the patched version that resolves all known advisories of this package -->
<ItemGroup>
   <PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
</ItemGroup>

Transitive Software Composition Analysis (SCA)

Raises an issue per NuGet package with known GitHub security advisories (https://github.com/advisories?query=+ecosystem%3Anuget) used by a package used by the application — hence transitive, unlike the rule Software Composition Analysis (SCA). The issue is reported on the first type (alphabetically) using a third-party assembly using the affected package.

Flagged Code

<!-- Acme.Sdk 2.1.0 depends on Newtonsoft.Json 12.0.1 (advisory GHSA-5crp-9r3c-p9vr) -->
<!-- Newtonsoft.Json is not referenced directly: the advisory is transitive -->
<ItemGroup>
   <PackageReference Include="Acme.Sdk" Version="2.1.0" />
</ItemGroup>

<!-- Acme.Sdk 2.2.0 depends on Newtonsoft.Json 13.0.1, which has no known advisory -->
<ItemGroup>
   <PackageReference Include="Acme.Sdk" Version="2.2.0" />
</ItemGroup>
<!-- Alternative when no such Acme.Sdk version exists: pin the transitive package -->
<ItemGroup>
   <PackageReference Include="Acme.Sdk" Version="2.1.0" />
   <PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
</ItemGroup>

Don't hard-code secrets in constants

Matches const string fields, and static readonly string fields whose static constructor only manipulates strings, named like a password, API key, private key, connection string, token, client secret or signing key. A literal secret ships in every build, leaks through decompilation, source control history and crash dumps, and cannot be rotated without a redeploy.

Names that merely designate a setting (PasswordFieldName, ApiKeyHeader, PasswordMinLength, PasswordHash...) or a user-facing text (PasswordTooltip, InvalidSecretMessage...) are excluded. The rule cannot see the literal value: a placeholder like "CHANGE_ME" or an empty string is reported too, suppress such issues.

This is CWE-798 Use of Hard-coded Credentials.

Flagged Code

static class DbSettings {
   const string Password = "P@ssw0rd!";                       // flagged: const secret
   static readonly string ApiKey = "sk-live-" + "4f9c2e1a";   // flagged: only string ops
}

class DbSettings {
   readonly string _password;
   readonly string _apiKey;
   DbSettings(IConfiguration config) {
      _password = config["Db:Password"];    // user-secrets, environment or key vault
      _apiKey = Environment.GetEnvironmentVariable("API_KEY");
   }
}

Review credentials built from hard-coded values

Matches methods that create a NetworkCredential, set the Password of a connection string builder, or load a PKCS#12 certificate with a password, while nothing in the method can supply that secret at runtime: no string parameter, no string field read, no call returning a string (configuration, environment, property getter, secret store). The only remaining source is a string literal.

This is CWE-798 Use of Hard-coded Credentials.

Flagged Code

static HttpClientHandler CreateHandler() {
   var handler = new HttpClientHandler();
   handler.Credentials = new NetworkCredential("svc-account", "P@ssw0rd!");   // flagged
   return handler;
}

static HttpClientHandler CreateHandler(IConfiguration config) {
   var handler = new HttpClientHandler();
   string user = config["Svc:User"];           // the secret comes from configuration
   string password = config["Svc:Password"];
   handler.Credentials = new NetworkCredential(user, password);
   return handler;
}

Don't use insecure deserializers

Matches methods using a deserializer that instantiates arbitrary types named in the payload: BinaryFormatter (obsolete SYSLIB0011, removed from .NET 9), SoapFormatter, NetDataContractSerializer, LosFormatter, ObjectStateFormatter, JavaScriptSerializer with a type resolver, or Newtonsoft.Json with TypeNameHandling set. Gadget chains available in the framework turn such deserialization of untrusted input into remote code execution: https://learn.microsoft.com/dotnet/standard/serialization/binaryformatter-security-guide

This is CWE-502 Deserialization of Untrusted Data.

Flagged Code

static Order Load(byte[] payload) {
   var formatter = new BinaryFormatter();                       // flagged: BinaryFormatter
   using var stream = new MemoryStream(payload);
   return (Order)formatter.Deserialize(stream);
}
static JsonSerializerSettings Settings() =>
   new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.All };   // flagged

static Order Load(byte[] payload) =>
   JsonSerializer.Deserialize<Order>(payload);                  // System.Text.Json, fixed type
static JsonSerializerSettings Settings() =>
   new JsonSerializerSettings();                                // TypeNameHandling stays None

Don't use weak hash algorithms (MD5, SHA1)

Matches methods calling MD5, SHA1, RIPEMD160 or HMACMD5 constructors, factories (MD5.Create()), one-shot helpers (SHA1.HashData()) or selecting them through HashAlgorithmName.MD5 / HashAlgorithmName.SHA1. Practical collision attacks exist against MD5 (since 2004) and SHA1 (SHAttered, 2017): https://shattered.io/ . NIST deprecated SHA1 for digital signatures in 2011 and plans its full retirement by 2030.

This is CWE-328 Use of Weak Hash.

Flagged Code

static string Fingerprint(byte[] data) {
   using var md5 = MD5.Create();                                // flagged: MD5
   return Convert.ToHexString(md5.ComputeHash(data));
}
static byte[] Digest(byte[] data) => SHA1.HashData(data);       // flagged: SHA1

static string Fingerprint(byte[] data) {
   using var sha256 = SHA256.Create();
   return Convert.ToHexString(sha256.ComputeHash(data));
}
static byte[] Digest(byte[] data) => SHA256.HashData(data);

Don't use DES/3DES/RC2 weak cipher algorithms

Since 2005 the NIST no longer considers DES and 3DES cipher algorithms secure (3DES was fully withdrawn at the end of 2023). RC2 shares the 64-bit block size that makes them vulnerable to the Sweet32 birthday attack. Rijndael / RijndaelManaged are obsolete in .NET (SYSLIB0022): they only add non-standard block sizes to AES and are not FIPS validated. Sources: https://www.nist.gov/news-events/news/2005/06/nist-withdraws-outdated-data-encryption-standard https://sweet32.info/

This is CWE-327 Use of a Broken or Risky Cryptographic Algorithm.

Flagged Code

static byte[] Encrypt(byte[] plain, byte[] key, byte[] iv) {
   using var cipher = TripleDES.Create();                       // flagged: 3DES
   cipher.Key = key;
   cipher.IV = iv;
   using var encryptor = cipher.CreateEncryptor();
   return encryptor.TransformFinalBlock(plain, 0, plain.Length);
}

static byte[] Encrypt(byte[] plain, byte[] key, byte[] iv) {
   using var cipher = Aes.Create();                             // AES (or AesGcm)
   cipher.Key = key;
   cipher.IV = iv;
   using var encryptor = cipher.CreateEncryptor();
   return encryptor.TransformFinalBlock(plain, 0, plain.Length);
}

Don't use weak password-based key derivation

Matches methods creating PasswordDeriveBytes (PBKDF1, obsolete SYSLIB0041) or Rfc2898DeriveBytes through a constructor without a HashAlgorithmName parameter: such constructors silently use SHA1 and default to 1000 iterations, orders of magnitude below the OWASP 2023 recommendation (600.000 iterations for PBKDF2-HMAC-SHA256).

This is CWE-916 Use of Password Hash With Insufficient Computational Effort.

Flagged Code

static byte[] DeriveKey(string password, byte[] salt) {
   using var kdf = new Rfc2898DeriveBytes(password, salt, 1000);   // flagged: SHA1 default
   return kdf.GetBytes(32);
}
static byte[] LegacyKey(string password, byte[] salt) =>
   new PasswordDeriveBytes(password, salt).GetBytes(20);           // flagged: PBKDF1

static byte[] DeriveKey(string password, byte[] salt) =>
   Rfc2898DeriveBytes.Pbkdf2(password, salt, 600_000, HashAlgorithmName.SHA256, 32);
// Or the constructor overload that names the hash algorithm explicitly:
static byte[] DeriveKeyCtor(string password, byte[] salt) {
   using var kdf = new Rfc2898DeriveBytes(password, salt, 600_000, HashAlgorithmName.SHA256);
   return kdf.GetBytes(32);
}

Don't use the ECB encryption mode

Matches methods that call the one-shot ECB APIs of SymmetricAlgorithm (Aes, TripleDES, DES, RC2): EncryptEcb(), DecryptEcb(), TryEncryptEcb(), TryDecryptEcb() and GetCiphertextLengthEcb().

In Electronic Codebook (ECB) mode every block is encrypted independently with the same key, hence two identical plaintext blocks produce two identical ciphertext blocks. An attacker can spot repeated structures, swap or replay blocks, and in many cases recover the content without the key. This is CWE-327 Use of a Broken or Risky Cryptographic Algorithm (OWASP Top 10 A02 Cryptographic Failures).

Assigning CipherMode.ECB to the Mode property cannot be detected because enum values are not visible in the compiled code.

Flagged Code

static byte[] Encrypt(byte[] plaintext, byte[] key) {
   using var aes = Aes.Create();
   aes.Key = key;
   return aes.EncryptEcb(plaintext, PaddingMode.PKCS7);   // flagged: ECB
}

static byte[] Encrypt(byte[] plaintext, byte[] key, byte[] nonce, out byte[] tag) {
   using var aes = new AesGcm(key, AesGcm.TagByteSizes.MaxSize);
   var ciphertext = new byte[plaintext.Length];
   tag = new byte[AesGcm.TagByteSizes.MaxSize];
   aes.Encrypt(nonce, plaintext, ciphertext, tag);       // authenticated encryption
   return ciphertext;
}

Don't disable certificate validation

Matched methods replace the certificate validation of a TLS client or server: ServicePointManager.ServerCertificateValidationCallback, HttpClientHandler.ServerCertificateCustomValidationCallback (or its DangerousAcceptAnyServerCertificateValidator), SslClientAuthenticationOptions.RemoteCertificateValidationCallback (used by SocketsHttpHandler), an SslStream constructor taking a callback, the obsolete ServicePointManager.CertificatePolicy, or Kestrel's ClientCertificateValidation. These callbacks are mostly written to accept a self-signed or expired certificate, which means trusting any certificate: a vulnerability to man-in-the-middle attacks https://en.wikipedia.org/wiki/Man-in-the-middle_attack

This is CWE-295 Improper Certificate Validation.

Flagged Code

public HttpClient CreateClient() {
   var handler = new HttpClientHandler();
   // flagged: any certificate is trusted, a man-in-the-middle goes unnoticed
   handler.ServerCertificateCustomValidationCallback = (msg, cert, chain, errors) => true;
   return new HttpClient(handler);
}

public HttpClient CreateClient() {
   // The issuing CA is installed in the machine trust store: the default
   // validation checks the whole chain, no callback is needed.
   var handler = new HttpClientHandler();
   return new HttpClient(handler);
}

Don't hard-code TLS/SSL protocol versions

Matches methods setting ServicePointManager.SecurityProtocol, HttpClientHandler.SslProtocols, SslClientAuthenticationOptions.EnabledSslProtocols, Kestrel HttpsConnectionAdapterOptions.SslProtocols, or calling an SslStream.Authenticate... overload with an explicit SslProtocols. Microsoft's guidance since .NET Framework 4.7 / .NET Core is to leave the protocol at SystemDefault / None so that the operating system picks the strongest version available and drops SSL 3.0, TLS 1.0 and TLS 1.1 as they are retired: https://learn.microsoft.com/dotnet/framework/network-programming/tls

This is CWE-326 Inadequate Encryption Strength when the pinned list includes an obsolete version.

Flagged Code

public HttpClient CreateClient() {
   // flagged: freezes the application on TLS 1.2 and blocks TLS 1.3
   ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
   var handler = new HttpClientHandler { SslProtocols = SslProtocols.Tls12 };  // flagged
   return new HttpClient(handler);
}

public HttpClient CreateClient() {
   // Target .NET Framework 4.7+ or .NET Core and leave the protocol to the OS
   // (SystemDefault): the strongest version is negotiated, retired ones drop out.
   return new HttpClient(new HttpClientHandler());
}

Review commands vulnerable to SQL injection

Matches methods creating a DB command (like SqlCommand) that call an Execute method without using command parameters: prone to SQL Injection https://en.wikipedia.org/wiki/SQL_injection since malicious SQL might be injected in string parameter values.

False positives are possible; review matches and suppress issues when needed. To limit them, the rule also checks command parameters access from sub method calls (a solid indication of non-vulnerability).

Flagged Code

public int CountUsers(SqlConnection connection, string name) {
   var sql = "SELECT COUNT(*) FROM Users WHERE Name = '" + name + "'";
   using var command = new SqlCommand(sql, connection);  // flagged: no command parameter
   return (int)command.ExecuteScalar();
}

public int CountUsers(SqlConnection connection, string name) {
   const string sql = "SELECT COUNT(*) FROM Users WHERE Name = @name";
   using var command = new SqlCommand(sql, connection);
   command.Parameters.AddWithValue("@name", name);  // parameterized: not matched
   return (int)command.ExecuteScalar();
}

Review data adapters vulnerable to SQL injection

Matches methods creating a DB adapter (like SqlDataAdapter) that call Fill() without using DB command parameters: prone to SQL Injection https://en.wikipedia.org/wiki/SQL_injection since malicious SQL might be injected in string parameter values.

False positives are possible; review matches and suppress issues when needed. To limit them, the rule also checks command parameters access from sub method calls (a solid indication of non-vulnerability).

Flagged Code

public DataTable LoadOrders(SqlConnection connection, string customerId) {
   var sql = "SELECT * FROM Orders WHERE CustomerId = '" + customerId + "'";
   using var adapter = new SqlDataAdapter(sql, connection);  // flagged: no command parameter
   var table = new DataTable();
   adapter.Fill(table);
   return table;
}

public DataTable LoadOrders(SqlConnection connection, string customerId) {
   const string sql = "SELECT * FROM Orders WHERE CustomerId = @customerId";
   using var adapter = new SqlDataAdapter(sql, connection);
   adapter.SelectCommand.Parameters.AddWithValue("@customerId", customerId);  // parameterized
   var table = new DataTable();
   adapter.Fill(table);
   return table;
}

Review raw SQL built from composed strings

Matches methods that call an Entity Framework Core Raw entry point (FromSqlRaw(), ExecuteSqlRaw(), SqlQueryRaw()) or a Dapper Query / Execute member, while also building strings in the same body (String.Concat(), Format(), Join(), interpolation, StringBuilder). These members hand the SQL text to the database verbatim, so a composed fragment coming from a request, a file name or a configuration value is executed as SQL: SQL Injection https://en.wikipedia.org/wiki/SQL_injection

The rules Review commands vulnerable to SQL injection and Review data adapters vulnerable to SQL injection only cover ADO.NET commands, which modern code rarely uses directly. This rule covers the ORM path.

False positives are possible when every composed fragment is a constant or an internally generated identifier; review matches and suppress issues when needed.

This is CWE-89 SQL Injection (OWASP Top 10 A03 Injection).

Flagged Code

public List<Blog> FindBlogs(BloggingContext db, string name) {
   var sql = $"SELECT * FROM Blogs WHERE Name = '{name}'";  // SQL composed in the method
   return db.Blogs.FromSqlRaw(sql).ToList();  // flagged: the composed text runs verbatim
}

public List<Blog> FindBlogs(BloggingContext db, string name) {
   // FromSql takes a FormattableString: each hole becomes a DbParameter
   return db.Blogs.FromSql($"SELECT * FROM Blogs WHERE Name = {name}").ToList();
}

Review LDAP filters composed from strings

Matches methods that assign DirectorySearcher.Filter, construct a DirectorySearcher, a SearchRequest or a DirectoryEntry from a string, or call LdapConnection.Search(), while also assembling a string in the same method (String.Concat(), String.Format(), interpolation, StringBuilder).

LDAP filters have their own syntax: a value containing )(uid=) or \) closes the intended clause and opens another, which turns a login lookup into a query that matches every user, or bypasses the authentication altogether. This is LDAP injection, CWE-90 (OWASP Top 10 A03 Injection).

Flagged Code

static SearchResult FindUser(DirectoryEntry root, string login) {
   var searcher = new DirectorySearcher(root);
   searcher.Filter = "(&(objectClass=user)(sAMAccountName=" + login + "))";   // flagged
   return searcher.FindOne();
}

static SearchResult FindUser(DirectoryEntry root, string login) {
   var searcher = new DirectorySearcher(root);
   searcher.Filter = LdapFilter.ForUser(login);   // escaped and composed in one reviewed helper
   return searcher.FindOne();
}
static class LdapFilter {
   public static string ForUser(string login) =>
      "(&(objectClass=user)(sAMAccountName=" + Escape(login) + "))";
   static string Escape(string v) =>            // RFC 4515: escape \ * ( ) and NUL
      v.Replace(@"\", @"\5c").Replace("*", @"\2a").Replace("(", @"\28")
       .Replace(")", @"\29").Replace("\0", @"\00");
}

Don't enable external XML entity resolution (XXE)

Matches methods that create an XmlUrlResolver (or the obsolete XmlSecureResolver), enable XsltSettings.TrustedXslt / EnableScript / EnableDocumentFunction, or call the obsolete ProhibitDtd setter. With external entity resolution enabled, a crafted document can read local files (*file:///etc/passwd*), reach internal HTTP endpoints (SSRF) or explode memory (billion laughs). https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#net

This is CWE-611 Improper Restriction of XML External Entity Reference.

Flagged Code

public XmlReader OpenUntrusted(Stream xml) {
   var settings = new XmlReaderSettings {
      DtdProcessing = DtdProcessing.Parse,
      XmlResolver = new XmlUrlResolver()  // flagged: external entities get fetched
   };
   return XmlReader.Create(xml, settings);
}

public XmlReader OpenUntrusted(Stream xml) {
   var settings = new XmlReaderSettings {
      DtdProcessing = DtdProcessing.Prohibit,  // the default
      XmlResolver = null
   };
   return XmlReader.Create(xml, settings);
}

Review processes started with a composed arguments string

Matches methods that start a process with Process.Start(fileName, arguments), new ProcessStartInfo(fileName, arguments) or by assigning ProcessStartInfo.Arguments, while also building strings (String.Concat(), Format(), Join(), interpolation, StringBuilder) and never using the ArgumentList collection. A single arguments string is re-parsed by the target program (or by the shell when UseShellExecute is true): quotes, spaces, &, | or ; in an interpolated value change the command executed.

This is CWE-78 OS Command Injection (review: the rule cannot tell whether the composed fragments are user-controlled).

Flagged Code

public void Convert(string inputFile) {
   // flagged: re-parsed by ffmpeg, a quote in inputFile injects extra arguments
   var arguments = $"-i \"{inputFile}\" -o output.mp4";
   Process.Start("ffmpeg", arguments);
}

public void Convert(string inputFile) {
   var startInfo = new ProcessStartInfo("ffmpeg") { UseShellExecute = false };
   startInfo.ArgumentList.Add("-i");
   startInfo.ArgumentList.Add(inputFile);  // quoted per argument, nothing is re-parsed
   startInfo.ArgumentList.Add("-o");
   startInfo.ArgumentList.Add("output.mp4");
   Process.Start(startInfo);
}

Review web endpoints building file paths from their parameters

Matches public actions of MVC controllers, API controllers and Razor page models that take a string parameter, build a file path with it (Path.Combine(), concatenation, interpolation) and then read or write the file system, without calling Path.GetFileName(), Path.GetFullPath() or Path.IsPathRooted() first.

A segment such as ..\..\appsettings.json or an absolute path then escapes the intended directory: path traversal. Note that Path.Combine() makes this worse, since it discards everything before an absolute second argument.

This is CWE-22 Improper Limitation of a Pathname to a Restricted Directory (OWASP Top 10 A01 Broken Access Control).

Flagged Code

public class DownloadController : ControllerBase {
   [HttpGet("download")]
   public IActionResult Download(string fileName) {
      var path = Path.Combine(_root, fileName);  // flagged: "..\..\web.config" escapes _root
      return File(System.IO.File.ReadAllBytes(path), "application/octet-stream");
   }
}

public class DownloadController : ControllerBase {
   [HttpGet("download")]
   public IActionResult Download(string fileName) {
      var safeName = Path.GetFileName(fileName);  // drops any directory segment
      var path = Path.Combine(_root, safeName);
      return File(System.IO.File.ReadAllBytes(path), "application/octet-stream");
   }
}

Review custom archive extraction (Zip Slip)

Matches methods that read the name of an archive entry (ZipArchiveEntry.FullName, TarEntry.Name, SharpZipLib ZipEntry.Name, SharpCompress IEntry.Key), build a path with it (Path.Combine(), concatenation, interpolation) and write to the file system, without both resolving the path with Path.GetFullPath() and checking it with String.StartsWith() against the destination root, and without reducing the name with Path.GetFileName().

Archive entry names are data supplied by whoever built the archive. A name such as ..\..\..\Windows\Startup\evil.cmd combined with the destination directory escapes it and overwrites an arbitrary file: the Zip Slip vulnerability, CWE-22 Improper Limitation of a Pathname to a Restricted Directory (OWASP Top 10 A01 Broken Access Control). Path.Combine() makes it worse by discarding the destination when the entry name is an absolute path.

Path.GetFullPath() alone does not suppress the issue: it resolves the .. segments but verifies nothing.

Flagged Code

static void Extract(ZipArchive archive, string destination) {
   foreach (var entry in archive.Entries) {
      var path = Path.Combine(destination, entry.FullName);   // flagged: no containment
      entry.ExtractToFile(path, overwrite: true);
   }
}

static void Extract(ZipArchive archive, string destination) {
   var root = Path.GetFullPath(destination + Path.DirectorySeparatorChar);
   foreach (var entry in archive.Entries) {
      var path = Path.GetFullPath(Path.Combine(root, entry.FullName));
      if (!path.StartsWith(root, StringComparison.Ordinal))
         throw new IOException("Entry outside of the destination: " + entry.FullName);
      entry.ExtractToFile(path, overwrite: true);
   }
}

Review assemblies and types loaded from runtime-provided names

Matches methods that load assemblies from a path or from bytes (Assembly.LoadFrom(), LoadFile(), Load(byte[]), AssemblyLoadContext.LoadFromAssemblyPath(), LoadFromStream()), instantiate a type from assembly and type names (Activator.CreateInstance(assemblyName, typeName)), or, in a method receiving a string, combine Type.GetType(string) with Activator.CreateInstance(Type). Plugin systems legitimately do this, but a path or name that comes from a request, a configuration file, a database or a user-writable directory turns it into remote code execution.

This is CWE-470 Use of Externally-Controlled Input to Select Classes or Code and CWE-829 Inclusion of Functionality from Untrusted Control Sphere (review).

Flagged Code

public object LoadPlugin(string pluginPath, string typeName)
{
   var asm = Assembly.LoadFrom(pluginPath);                  // flagged: path from caller
   return Activator.CreateInstance(asm.GetType(typeName));
}

static readonly Dictionary<string, Func<IPlugin>> s_Plugins = new()
{
   ["csv"] = () => new CsvPlugin(),
   ["json"] = () => new JsonPlugin()
};
public IPlugin LoadPlugin(string name)
{
   // The name maps to a closed set of known types: nothing is resolved by reflection.
   if (!s_Plugins.TryGetValue(name, out var create)) throw new ArgumentException(name);
   return create();
}

Review web endpoints without [Authorize] nor [AllowAnonymous]

Matches ASP.NET Core controllers, SignalR hubs and legacy MVC / Web API controllers that are not authorized at class level (including inherited classes) and expose public actions carrying neither an authorization attribute ([Authorize], a derived attribute, or any attribute implementing IAuthorizeData) nor an explicit [AllowAnonymous]. The rule stays silent when the application sets a global fallback policy (AuthorizationOptions.FallbackPolicy) or registers a global AuthorizeFilter, since every endpoint is then protected by default.

An endpoint that is anonymous by omission rather than by decision is a classic broken access control (OWASP A01:2021, CWE-306 Missing Authentication for Critical Function).

Flagged Code

public class OrdersController : ControllerBase        // flagged: no [Authorize] on the class
{
   [HttpGet("{id}")]                                    // no [Authorize], no [AllowAnonymous]
   public IActionResult Get(int id) => Ok(_orders.Find(id));

   [HttpGet("status")]
   public IActionResult Status() => Ok("up");
}

[Authorize]                                          // every action requires authentication
public class OrdersController : ControllerBase
{
   [HttpGet("{id}")]
   public IActionResult Get(int id) => Ok(_orders.Find(id));

   [AllowAnonymous]                                     // explicit decision for the public probe
   [HttpGet("status")]
   public IActionResult Status() => Ok("up");
}

Review state-changing endpoints opened to anonymous callers

Matches actions carrying both [AllowAnonymous] and a state-changing HTTP verb attribute. [AllowAnonymous] wins over every [Authorize] on the class, the base class and the global filters, so such an action answers any unauthenticated request, whatever the rest of the configuration says. That is intended for sign-in, sign-up, password-recovery, webhook and callback endpoints, which the rule skips by name, and rarely intended anywhere else.

This is CWE-284 Improper Access Control (OWASP Top 10 A01 Broken Access Control).

Flagged Code

[Authorize]
public class CommentsController : ControllerBase
{
   [AllowAnonymous]                                     // flagged: wins over [Authorize]
   [HttpDelete("{id}")]
   public IActionResult DeleteComment(int id) { _comments.Remove(id); return NoContent(); }
}

[Authorize]
public class CommentsController : ControllerBase
{
   [HttpDelete("{id}")]                                 // the class policy applies again
   public IActionResult DeleteComment(int id) { _comments.Remove(id); return NoContent(); }

   [AllowAnonymous]
   [HttpPost("login")]                                  // sign-in endpoints are skipped by name
   public IActionResult Login(LoginModel model) => SignInAsync(model);
}

Review state-changing MVC actions without anti-forgery validation

Matches view-based MVC controllers (deriving from Microsoft.AspNetCore.Mvc.Controller or System.Web.Mvc.Controller) whose POST/PUT/DELETE/PATCH actions are not covered by [ValidateAntiForgeryToken] or [AutoValidateAntiforgeryToken] on the action, the class chain, or a global filter, and are not explicitly exempted with [IgnoreAntiforgeryToken]. Controllers or actions tagged [ApiController] or [Consumes(...)] are skipped: they are not reachable from an HTML form. Cookie-authenticated form posts without a token are the textbook CSRF (CWE-352).

Flagged Code

public class AccountController : Controller
{
   [HttpPost]                                           // flagged: no anti-forgery validation
   public IActionResult UpdateEmail(string email)
   {
      _accounts.SetEmail(User.Identity.Name, email);
      return RedirectToAction("Index");
   }
}

public class AccountController : Controller
{
   [HttpPost]
   [ValidateAntiForgeryToken]                           // the form must carry the token
   public IActionResult UpdateEmail(string email)
   {
      _accounts.SetEmail(User.Identity.Name, email);
      return RedirectToAction("Index");
   }
}

Review HTML-encoding bypasses

Matches methods that bypass the HTML encoder that Razor and Blazor apply by default: Html.Raw(), new HtmlString(), new MarkupString(), MvcHtmlString.Create(), and the AppendHtml(string) / SetHtmlContent(string) members of tag helpers and IHtmlContentBuilder.

Each of these members tells the view engine trust this string, it is already HTML. When the string contains data that a user controls (a comment, a profile field, a query string value), a payload such as <script> is rendered as markup and executed in the browser of every visitor: cross-site scripting. This is CWE-79 (OWASP Top 10 A03 Injection).

Compiled Razor views are generated methods and are deliberately included: the issue then points to the view. Methods that also assemble the string (String.Concat(), String.Format(), interpolation, StringBuilder) are reported with the High severity, since the raw fragment is built rather than picked from a trusted source.

Flagged Code

public class CommentViewComponent : ViewComponent {
   public IViewComponentResult Invoke(Comment comment) {
      var html = new HtmlString("<p>" + comment.Body + "</p>");   // flagged: raw HTML
      return View(html);
   }
}

public class CommentViewComponent : ViewComponent {
   public IViewComponentResult Invoke(Comment comment) {
      return View(comment);   // the view writes @Model.Body, encoded by Razor
   }
}

Review explicitly disabled request validation

Matches ASP.NET MVC controllers, actions and model properties that explicitly opt out of request validation with [ValidateInput(false)] or [AllowHtml].

Request validation is the ASP.NET safety net that rejects requests containing HTML-looking input. Disabling it is legitimate for rich-text editors, but then every value received through that action or property can carry a script: it must be sanitized with an allow-list sanitizer before being stored, and HTML-encoded whenever it is rendered. A controller-level [ValidateInput(false)] is reported with the High severity since it opens every action of the controller.

This is CWE-79 Cross-site Scripting (OWASP Top 10 A03 Injection). ASP.NET Core has no request validation: the rule is silent there.

Flagged Code

[ValidateInput(false)]                                   // flagged: whole controller
public class ArticleController : Controller {
   [HttpPost]
   public ActionResult Save(Article article) {
      _repository.Save(article);                         // raw HTML stored as-is
      return RedirectToAction("Index");
   }
}

public class ArticleController : Controller {                // request validation stays on
   [HttpPost]
   public ActionResult Save(Article article) {              // article.Body is Markdown, not HTML
      _repository.Save(article);                            // markup submissions are rejected
      return RedirectToAction("Index");
   }
}

Review redirects to a URL that is not validated as local

Matches methods calling Redirect(url) (or its permanent / preserve-method variants) on a controller, page model, HTTP response or results helper, that take a string parameter or read request data (query, form, headers, route values) and never call Url.IsLocalUrl() nor LocalRedirect(). A returnUrl forwarded as-is is the classic open redirect used in phishing campaigns.

This is CWE-601 URL Redirection to Untrusted Site (review).

Flagged Code

public IActionResult AfterLogin(string returnUrl)
{
   return Redirect(returnUrl);                          // flagged: any absolute URL is accepted
}

public IActionResult AfterLogin(string returnUrl)
{
   if (Url.IsLocalUrl(returnUrl))
      return LocalRedirect(returnUrl);                  // only paths on this site
   return RedirectToAction("Index");
}

Review request-influenced outbound HTTP calls (SSRF)

Matches public actions of MVC controllers, API controllers, Razor page models and SignalR hubs that take a string or a Uri parameter and either call an HTTP client directly (HttpClient, HttpRequestMessage, WebRequest, WebClient, RestSharp) or carry a name that says they fetch a remote resource (Url, Uri, Remote, Fetch, Download, Proxy, Webhook, Callback). The callDepthToHttpClient column gives the length of the shortest call path to an HTTP client (0 when the client sits behind an interface), and validatesUri tells whether the action itself inspects the host, scheme or IP address of a URI.

The rule does not prove that the received value flows into the outbound request: it lists the endpoints where that flow must be reviewed. When the value does reach the request address, an attacker steers the server toward hosts it can reach and the attacker cannot: internal admin services, cloud instance metadata (169.254.169.254), databases. This is server-side request forgery, CWE-918 (OWASP Top 10 A10).

Flagged Code

public class PreviewController : ControllerBase {
   [HttpGet("preview")]
   public async Task<IActionResult> Preview(string url) {          // flagged: calls HttpClient
      var html = await _httpClient.GetStringAsync(url);            // url chosen by the caller
      return Content(Summarize(html));
   }
}

public class PreviewController : ControllerBase {
   [HttpGet("preview")]
   public async Task<IActionResult> Preview(Guid feedId) {         // an identifier, not an address
      var feed = await _feeds.FindAsync(feedId);                   // address from trusted storage
      if (feed == null) return NotFound();
      var html = await _httpClient.GetStringAsync(feed.Url);
      return Content(Summarize(html));
   }
}

Review insecure ASP.NET Core CORS policies and unguarded developer exception page

Matches startup methods where: - a CORS policy combines AllowAnyOrigin() (or a permissive SetIsOriginAllowed()) with AllowCredentials(): any website can then make authenticated cross-origin requests with the user's cookies. ASP.NET Core rejects the literal AllowAnyOrigin + AllowCredentials pair at runtime, which is why SetIsOriginAllowed(_ => true) is the common workaround, hence its presence in this rule; - UseDeveloperExceptionPage() is called without an IsDevelopment() (or IsEnvironment()) check in the same method or its caller: stack traces, source snippets, headers and cookies would be shown to anyone triggering an exception in production.

These are CWE-942 Permissive Cross-domain Policy with Untrusted Domains and CWE-209 Generation of Error Message Containing Sensitive Information.

Flagged Code

builder.Services.AddCors(o => o.AddPolicy("open", p =>
   p.SetIsOriginAllowed(_ => true)                       // flagged: any origin...
    .AllowCredentials()));                               // ...with the user's cookies
var app = builder.Build();
app.UseDeveloperExceptionPage();                         // flagged: no environment check

builder.Services.AddCors(o => o.AddPolicy("partners", p =>
   p.WithOrigins("https://partner.example.com")
    .AllowCredentials()));
var app = builder.Build();
if (app.Environment.IsDevelopment())
   app.UseDeveloperExceptionPage();
else
   app.UseExceptionHandler("/error");

Review cookies created without HttpOnly and Secure flags

Matches methods that instantiate CookieOptions, CookieBuilder or HttpCookie without assigning both HttpOnly and Secure (or SecurePolicy), and methods calling Response.Cookies.Append(name, value) without options while the application does not use UseCookiePolicy(). The rule cannot see the assigned value: it reports the missing assignment, which in practice means the insecure default.

This is CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag and CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute.

Flagged Code

public void RememberSession(string token)
{
   var options = new CookieOptions { Expires = DateTimeOffset.UtcNow.AddDays(7) };
   Response.Cookies.Append("session", token, options);  // flagged: HttpOnly and Secure not set
}

public void RememberSession(string token)
{
   var options = new CookieOptions
   {
      Expires = DateTimeOffset.UtcNow.AddDays(7),
      HttpOnly = true,
      Secure = true,
      SameSite = SameSiteMode.Strict
   };
   Response.Cookies.Append("session", token, options);
}

Review regular expressions without a match timeout (ReDoS)

Matches methods that create or run a Regex through an overload without a TimeSpan matchTimeout argument (constructors, Regex.IsMatch(), Match(), Matches(), Replace(), Split(), Count(), EnumerateMatches()) or that declare a [GeneratedRegex] without the matchTimeoutMilliseconds argument. The .NET backtracking engine can be driven into catastrophic backtracking by crafted input, a Regular Expression Denial of Service (ReDoS): https://learn.microsoft.com/dotnet/standard/base-types/best-practices-regex#use-time-out-values The rule is muted when the application sets the process-wide REGEX_DEFAULT_MATCH_TIMEOUT through AppDomain.SetData().

This is CWE-1333 Inefficient Regular Expression Complexity.

Flagged Code

public bool IsValidTitle(string title)
{
   return Regex.IsMatch(title, @"^(\w+\s?)*$");    // flagged: no matchTimeout, nested quantifier
}

static readonly Regex s_Title =
   new Regex(@"^(\w+\s?)*$", RegexOptions.None, TimeSpan.FromMilliseconds(200));

public bool IsValidTitle(string title)
{
   return s_Title.IsMatch(title);                   // instance call, timeout set at construction
}

Review secrets compared with non-constant-time equality

Matches methods that compare strings or byte sequences with String.Equals(), ==, String.Compare() or SequenceEqual() and either compute a hash / MAC / derived key in the same body, or carry a name mentioning a token, signature, HMAC, secret, OTP, password, API key, digest or nonce. Ordinary equality short-circuits on the first mismatch, so the elapsed time leaks how many leading bytes were right: a timing side channel that has been exploited over networks.

This is CWE-208 Observable Timing Discrepancy.

Flagged Code

bool VerifyToken(string token, byte[] key, byte[] payload) {
   using var hmac = new HMACSHA256(key);
   string expected = Convert.ToHexString(hmac.ComputeHash(payload));
   return expected == token;   // flagged: == returns as soon as a byte differs
}

bool VerifyToken(string token, byte[] key, byte[] payload) {
   using var hmac = new HMACSHA256(key);
   byte[] expected = hmac.ComputeHash(payload);
   byte[] provided = Convert.FromHexString(token);
   return CryptographicOperations.FixedTimeEquals(expected, provided);
}

Review secrets passed to logging methods

Matches methods that call a logging API (ILogger / LoggerExtensions, Serilog, NLog, log4net, Trace, Debug, Console) and, in the same body, read a string field or property getter named like a password, API key, private key, token, client secret, connection string or credential. Logs are stored longer, replicated more widely and protected less than the secret store; a connection string or bearer token in a log line is one of the most frequent real-world credential leaks.

This is CWE-532 Insertion of Sensitive Information into Log File (review: the rule cannot tell whether the value is part of the message).

Flagged Code

private readonly string _connectionString;

void OpenDatabase(ILogger logger) {
   logger.LogInformation("Opening {Db}", _connectionString);   // flagged: secret logged
   using var connection = new SqlConnection(_connectionString);
   connection.Open();
}

private readonly string _connectionString;

void OpenDatabase(ILogger logger) {
   logger.LogInformation("Opening database {Db}", DatabaseName);   // non-secret value
   using var connection = CreateConnection();
   connection.Open();
}

SqlConnection CreateConnection() => new SqlConnection(_connectionString);   // logs nothing

Review security operations that log nothing

Matches publicly visible methods whose name denotes an authentication or authorization operation (sign-in, sign-out, authorize, password change or reset, token revocation) when no logging call is reachable within two call levels: not in the method, not in what it calls, not in what that calls.

A call through an interface or abstract method of the application counts as logging when one of its implementations logs: an IAppLogger<T> adapter over ILogger<T> is followed.

Login failures, access-control denials and credential changes are the events an incident responder looks for first. When they are not recorded, an attack cannot be detected while it happens nor reconstructed afterwards.

The rule is silent for an application that uses no logging framework at all, since it has nothing to compare against.

This is CWE-778 Insufficient Logging (OWASP Top 10 A09 Security Logging and Monitoring Failures).

Flagged Code

public async Task<IActionResult> Login(LoginModel model) {
   var user = await _users.FindByNameAsync(model.UserName);
   if (user == null || !_hasher.Verify(user, model.Password))
      return Unauthorized();   // flagged: the failed attempt leaves no trace
   await _signInManager.SignInAsync(user, model.RememberMe);
   return RedirectToAction("Index");
}

public async Task<IActionResult> Login(LoginModel model) {
   var user = await _users.FindByNameAsync(model.UserName);
   if (user == null || !_hasher.Verify(user, model.Password)) {
      _logger.LogWarning("Failed login for {User} from {Ip}", model.UserName, RemoteIp);
      return Unauthorized();
   }
   _logger.LogInformation("User {User} signed in", model.UserName);
   await _signInManager.SignInAsync(user, model.RememberMe);
   return RedirectToAction("Index");
}

Don't use System.Random for security purposes

System.Random is weak: its numbers can be predicted, which can lead to vulnerabilities in a security critical context (tokens, session ids, salts, password reset codes, CAPTCHA...).

This is CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator.

Flagged Code

string CreatePasswordResetCode() {
   var random = new Random();   // flagged: predictable generator
   return random.Next(100000, 999999).ToString();
}

string CreateSessionId() => Random.Shared.NextInt64().ToString("x");   // flagged: Random.Shared

string CreatePasswordResetCode() =>
   RandomNumberGenerator.GetInt32(100000, 1000000).ToString();

string CreateSessionId() => RandomNumberGenerator.GetHexString(32);

Don't use CoSetProxyBlanket and CoInitializeSecurity

Once managed code is JIT'ed and executed, it is too late to call CoInitializeSecurity() or CoSetProxyBlanket(): the CLR has already initialized the COM security environment for the whole process.

Flagged Code

[DllImport("ole32.dll")]   // flagged: P/Invoke declared and called from managed code
static extern int CoInitializeSecurity(IntPtr pSecDesc, int cAuthSvc, IntPtr asAuthSvc,
   IntPtr pReserved1, uint dwAuthnLevel, uint dwImpLevel, IntPtr pAuthList,
   uint dwCapabilities, IntPtr pReserved3);

static void Main() {
   CoInitializeSecurity(IntPtr.Zero, -1, IntPtr.Zero, IntPtr.Zero, 6, 3,
                        IntPtr.Zero, 0, IntPtr.Zero);
}

// Unmanaged C++ host shim, run before the CLR is loaded: managed code declares no P/Invoke
int wmain() {
   CoInitializeEx(nullptr, COINIT_MULTITHREADED);
   CoInitializeSecurity(nullptr, -1, nullptr, nullptr, RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
                        RPC_C_IMP_LEVEL_IMPERSONATE, nullptr, EOAC_NONE, nullptr);
   return RunManagedEntryPoint();
}

Review publicly visible event handlers

Review publicly visible event handlers (methods with the standard (Object,EventArgs) signature) running security critical actions: malicious code can subscribe them to an event to trigger the action on firing. Even with a security check, the handler can run from a chain of trusted callers and cannot detect malicious registration.

Flagged Code

public class AdminPanel {
   public void OnDeleteAllUsers(object sender, EventArgs e) {   // flagged: public handler
      _userStore.DeleteAll();
   }
}

public class AdminPanel {
   private void OnDeleteAllUsers(object sender, EventArgs e) {   // non-public handler
      if (!_currentUser.IsAdministrator) return;
      _userStore.DeleteAll();
   }
}

Pointers should not be publicly visible

Detects public or protected fields of type System.IntPtr or System.UIntPtr. Pointers access unmanaged memory; exposing them publicly lets malicious code read and write the application's unmanaged data — worse if the field is not read-only, since it can be changed to force the application onto arbitrary data.

Flagged Code

public class NativeBuffer {
   public IntPtr Handle;      // flagged: public, writable pointer
   protected UIntPtr Length;  // flagged: protected pointer
}

public class NativeBuffer {
   private readonly SafeHandle _handle;   // pointer wrapped in a SafeHandle
   private IntPtr _buffer;                // private pointer
   public int Length { get; }
}

Seal methods that satisfy non-public interfaces

Matches public virtual methods of non-sealed public classes that override a method of an internal interface. The non-public interface indicates a process meant to remain private: a malicious subclass can override the method behavior, which private implementation will then invoke — a security vulnerability.

Flagged Code

internal interface ILicenseChecker { bool IsLicensed(); }

public class Product : ILicenseChecker {
   public virtual bool IsLicensed() => _license.IsValid;   // flagged: a subclass can override it
}

internal interface ILicenseChecker { bool IsLicensed(); }

public sealed class Product : ILicenseChecker {
   public bool IsLicensed() => _license.IsValid;   // non-virtual method, sealed class
}

Restrict sensitive APIs to reviewed components

Matches application methods that call a sensitive API directly, while not being declared in one of the reviewed components named in the rule source: process execution (Process.Start()), dynamic loading (Assembly.Load(), Activator.CreateInstance(string), Type.GetType(string)), raw SQL (DbCommand.CommandText, EF Core Raw entry points, Dapper) and cryptographic primitives (Aes, RSA, HMAC, RandomNumberGenerator, Rfc2898DeriveBytes...).

This rule expresses an architectural policy rather than a defect: the few places allowed to touch such APIs are known, reviewed and kept small, so that argument escaping, path validation, parameterization and key management are implemented once. Every other call site is a bypass to review. The rule ships inactive: edit the reviewedTypes and reviewedNamespaces lists at the top of the query with the names of your wrappers, trim the API families you don't care about, then activate it. Until the lists are filled, every direct call would be reported.

Flagged Code

public class ReportExporter {
   public void OpenInViewer(string reportPath) {
      Process.Start("viewer.exe", reportPath);           // flagged: direct call outside wrappers
   }
}

public class ReportExporter {
   public void OpenInViewer(string reportPath) {
      _processRunner.Run("viewer.exe", reportPath);      // reviewed wrapper listed in the rule
   }
}
namespace MyCompany.Infrastructure.Security {
   public sealed class ProcessRunner {                    // validates and escapes arguments once
      public void Run(string exe, params string[] args) { /* ArgumentList, no shell */ }
   }
}

Methods that could have a lower visibility

Warns about methods declarable with a lower visibility (private < internal < public) without compilation error. Narrowing visibility promotes encapsulation by minimizing access scope.

Publicly visible methods are not matched (the rule cannot know if public was intentional); matched public methods are declared in non-public types. Public methods that could be internal in a non-public type are caught by Avoid public methods not publicly visible instead.

Methods tagged CannotDecreaseVisibilityAttribute or IsNotDeadCodeAttribute (from NDepend.API.dll, or declared in your own code) are not matched.

How to Fix:

Declare each matched method with the optimal visibility shown in the CouldBeDeclared column.

If you publish an API, many matched public methods should stay public: either add && !m.IsPubliclyVisible to the rule (coarse), or tag each method with CannotDecreaseVisibilityAttribute (finer).

Types that could have a lower visibility

Warns about types declarable with a lower visibility (private < internal < public) without compilation error. Narrowing visibility promotes encapsulation by minimizing consumption scope.

Publicly visible types are not matched (the rule cannot know if public was intentional); matched public types are nested in non-public types.

Types tagged CannotDecreaseVisibilityAttribute or IsNotDeadCodeAttribute (from NDepend.API.dll, or declared in your own code) are not matched.

How to Fix:

Declare each matched type with the optimal visibility shown in the CouldBeDeclared column.

If you publish an API, many matched public types should stay public: either add && !m.IsPubliclyVisible to the rule (coarse), or tag each type with CannotDecreaseVisibilityAttribute (finer).

Fields that could have a lower visibility

Warns about fields declarable with a lower visibility (private < internal < public) without compilation error. Narrowing visibility promotes encapsulation by minimizing consumption scope.

Publicly visible fields are not matched (the rule cannot know if public was intentional); matched public fields are declared in non-public types.

Fields tagged CannotDecreaseVisibilityAttribute or IsNotDeadCodeAttribute (from NDepend.API.dll, or declared in your own code) are not matched.

How to Fix:

Declare each matched field with the optimal visibility shown in the CouldBeDeclared column.

If you publish an API, some matched public fields should stay public: either add && !m.IsPubliclyVisible to the rule (coarse), or tag each field with CannotDecreaseVisibilityAttribute (finer).

Types that could be declared as private, nested in a parent type

Matches types that could be nested and declared private in another type: the parent type is the only consumer, and both are in the same namespace. This improves encapsulation by minimizing the type's consumption scope. Classes with extension methods cannot be nested and are not matched.

How to Fix:

Nest each matched type into the specified parent type as private. Nested private types are hardly testable though: skip types consumed directly by tests.

Avoid publicly visible constant fields

Warns about constant fields visible outside their assembly: their value gets hard-coded into client assemblies, so changing it requires recompiling all consumers, else the program runs with different in-memory values — bugs are lurking.

Enumeration values share this pitfall but cannot be static readonly, hence the && !f.IsEnumValue condition; keep it unless you banish public enumerations.

How to Fix:

Declare matched fields static readonly instead of constant: the value becomes safely changeable without recompiling clients.

Fields should be declared as private or protected

Matches mutable (non-constant, non-readonly) fields non-private, non-protected. Fields are implementation details and should be private (or protected if derived classes need them).

When a non-private field misbehaves, the culprit can be anywhere; a private field can only be assigned from its own class, usually one source file to look at.

Debt is proportional to the number of methods assigning the field.

How to Fix:

Declare the field private or readonly, refactoring outside usage away if possible. If external access is required, encapsulate it in a property: debug breakpoints on accessors simplify tracking read-write accesses.

Constructors of abstract classes should be declared as protected or private

Constructors of abstract classes can only be called from derived classes, and instances of an abstract class cannot be created: a public constructor there is wrong design. A private constructor means derived classes must be nested in the abstract class.

How to Fix:

Declare the constructor protected, or don't declare the type abstract.

Avoid public methods not publicly visible

Warns about public methods whose parent type is not public. There public means accessible wherever my parent type is visible — elegant to some developers, misleading to others. Deactivate the rule if you disagree; the debate: http://ericlippert.com/2014/09/15/internal-or-public/

Severity is Low: more an advice than a problem.

How to Fix:

Declare the method internal if used outside its type, else private.

Event handler methods should be declared as private or protected

An event handler (like OnClickButton()) should be private and only called on event firing — or protected, as some designers (e.g. ASP.NET) generate it so sub-classes can call it.

How to Fix:

If another class needs to call the handler, find a structure matching the actual concept: the other class doesn't want to click a button, it wants to do what clicking the button also does.

Wrong usage of CannotDecreaseVisibilityAttribute

NDepend.Attributes.CannotDecreaseVisibilityAttribute (from NDepend.API.dll, or declared in your own code) marks elements whose visibility is not optimal but shouldn't be modified — e.g. elements consumed through reflection, mocking, serialization, designers, COM, or reached by test code. It silences the not-optimal-visibility rules and expresses: Don't change the visibility else something will be broken.

This rule matches elements tagged with this attribute whose visibility is nevertheless already optimal.

When an element is used by test code, its optimal visibility is recomputed without taking test code users into account. If this visibility is more restrictive than the actual one, the element is exposed on purpose for tests: the attribute usage is valid and the element is not matched.

How to Fix:

Remove the now-useless CannotDecreaseVisibilityAttribute tagging of matched elements. Severity is Low: more an advice than a problem.

Exception classes should be declared as public

Custom exception classes offer finer details than standard exceptions, but catching code must have access to the exception class to use them.

How to Fix:

Declare custom exception classes public, catchable in every context.

Methods that should be declared as 'public' in C#, 'Public' in VB.NET

Lists internal methods consumed outside their assembly thanks to System.Runtime.CompilerServices.InternalsVisibleToAttribute, via the property NDepend.CodeModel.IMember.ShouldBePublic: https://www.ndepend.com/api/NDepend.CodeModel.IMember.html#NDepend_CodeModel_IMember_ShouldBePublic

A query (not a rule): it informs that the code relies on the peculiar InternalsVisibleToAttribute behavior, not that methods should be public.

Fields should be marked as ReadOnly when possible

Warns about instance and static fields declarable as readonly, based on IField.IsImmutable: https://www.ndepend.com/api/NDepend.CodeModel.IField.html#NDepend_CodeModel_IField_IsImmutable An IsImmutable field is only assigned by constructors of its class: its value stays constant through the object lifetime (instance field) or the program lifetime (static field).

readonly enhances robustness and readability: it defines a contract that the field is not altered after initialization, and enforces it.

How to Fix:

Declare the field with the C# readonly keyword (ReadOnly in VB.NET).

Avoid non-readonly static fields

Warns about static fields not declared read-only. Instance fields are the natural OOP artifact for mutable state; mutable static fields create confusion about runtime state and impair testability (the same mutable state is re-used per test). More: https://blog.ndepend.com/the-proper-usages-of-the-keyword-static-in-c/

How to Fix:

If assigned once per program lifetime, declare the field readonly and assign it inline or in the static constructor. Otherwise refactor to hold the state in an instance field.

Avoid static fields with a mutable field type

Warns about static fields with a mutable field type: they hold modifiable state. Instance fields are the natural OOP artifact for mutable state; such static fields create confusion about runtime state. More: https://blog.ndepend.com/the-proper-usages-of-the-keyword-static-in-c/

How to Fix:

Hold mutable states in objects passed explicitly wherever consumed, rather than in a static field modifiable from everywhere in the program.

Structures should be immutable

A structure or class is immutable if its instance fields are only assigned inline or from constructor(s).

Structures are value types: passing or assigning them works on copies, unlike classes (references). Modifying copies of mutable structures leads to confusion and errors. More: https://blog.ndepend.com/class-vs-struct-in-c-making-informed-choices/

How to Fix:

Make matched structures immutable: all passed by value copies then hold the same values, no surprises. Since C#7.2 the readonly keyword on a struct declaration enforces immutability. Changing a value then means consciously creating a new instance with the modified data.

Immutable struct should be declared as readonly

Declare immutable structures as readonly struct: the compiler and JIT learn the immutability intent and can optimize, e.g. passing/returning instances by-reference instead of copying them (no mutation risk). More: https://learn.microsoft.com/en-us/dotnet/csharp/write-safe-efficient-code#declare-immutable-structs-as-readonly

How to Fix:

Declare matched structures as readonly struct.

Property Getters should be pure

A property getter with side-effects is unexpected and counterintuitive for callers: getters should be pure, assigning no field.

To avoid matching lazy initialization at first access (an invisible implementation detail for clients), getters assigning a field only assigned by themselves and the corresponding setter are not matched, nor are fields with a name similar to the property name.

How to Fix:

Make matched property getters assign no field.

Estimated Debt: 2 minutes plus 5 minutes per field assigned and 5 minutes per other method assigning such field.

A field must not be assigned from outside its parent hierarchy types

Related to Fields should be declared as private: matches public or internal, mutable fields assigned from outside their parent class and subclasses. Fields are implementation details and should be private.

When a non-private field misbehaves, the culprit can be anywhere; a private field can only be assigned from its own class, usually one source file to look at.

How to Fix:

Declare matched fields protected or better private. A field exclusively referencing immutable states can stay accessible but must be declared readonly.

Estimated Debt: 5 minutes per method outside the parent hierarchy assigning the field.

Don't assign a field from many methods

A field assigned from many methods is a symptom of bug-prone code (constructors assigning the field are not counted). Threshold: 4+ assigning methods for instance fields; 3+ for static fields, whose global random accesses are even worse. Such anarchically assigned fields make runtime state hard to anticipate: code hard to read, debug and maintain, with hard-to-solve corrupted-state bugs.

With multiple threads there are alarming chances the code is unmaintainable and bugged — the rule of thumb is immutable objects. Corrupted reference-type state can yield NullReferenceException; corrupted value-type state can yield silently wrong results.

How to Fix:

No straight advice. Sometimes it is simple: e.g. an indentation field assigned by many writers just needs IndentPlus()/IndentMinus() methods. Sometimes a complex algorithm must be rethought and rewritten: the field may become a local variable or closure, or rethinking the parent object's lifetime and role can make it immutable (constructor-assigned only).

Estimated Debt: 4 minutes plus 5 minutes per method assigning the instance field, or 10 minutes per method assigning the static field.

Do not declare read only fields with mutable reference types

Violated when a public type contains a public read-only field of a mutable reference type. Misleading: readonly suggests a constant object, but only the reference is fixed — the referenced object's state can still change.

How to Fix:

Replace the field type with an immutable type, or declare the field private. Severity is Low: more an advice than a problem.

Public read only array fields can be modified

Violated when a publicly visible read-only field holds an array: the reference cannot change, but the array elements can. Code relying on the elements of a publicly accessible read-only array might contain an exploitable security vulnerability.

How to Fix:

Don't rely on the contents of a publicly accessible read-only array. Either:

- Replace the array with an unchangeable strongly typed collection, e.g. System.Collections.Generic.IReadOnlyList<T> ; System.Collections.Generic.IReadOnlyCollection<T> ; System.Collections.ReadOnlyCollectionBase

- Or replace the public field with a method returning a clone of a private array: modified clone elements are harmless.

Severity is Low: more an advice than a problem.

Types tagged with ImmutableAttribute must be immutable

A type is immutable if its instance fields are only assigned inline or from constructor(s). NDepend.Attributes.ImmutableAttribute (from NDepend.API.dll, or your own attribute, adapting the rule) expresses in code that a type is immutable; this rule continuously checks it and warns when a tagged type is no longer immutable.

How to Fix:

Find which modification broke immutability (the culpritFields list helps), then refactor the type back to immutability.

Estimated Debt: 5 minutes plus 10 minutes per culprit field.

Types immutable should be tagged with ImmutableAttribute

A type is immutable if its instance fields are only assigned inline or from constructor(s). This query lists immutable types not tagged with NDepend.Attributes.ImmutableAttribute. The attribute expresses in source code the intention that a class is and should remain immutable — an intention continuously checked by the rule Types tagged with ImmutableAttribute must be immutable.

How to Fix:

Tag matched types with ImmutableAttribute from NDepend.API.dll, or your own attribute (adapting this query).

Methods tagged with PureAttribute must be pure

A pure method changes no instance or static field: a function producing a result from inputs, simplifying code by limiting side-effects. A PureAttribute expresses purity in code; this rule continuously checks it and warns when a tagged method is no longer pure.

Use NDepend.Attributes.PureAttribute (from NDepend.API.dll), System.Diagnostics.Contracts.PureAttribute (honored by the compiler only with Microsoft Code Contract enabled), or your own PureAttribute (adapting the rule).

How to Fix:

Find which modification broke the method purity, then refactor it back to purity.

Pure methods should be tagged with PureAttribute

A pure method changes no instance or static field, simplifying code by limiting side-effects. This query lists pure methods not tagged with a PureAttribute. The attribute expresses in source code that a method is and should remain pure — an intention continuously checked by the rule Methods tagged with PureAttribute must be pure.

Not a rule by default: many methods would match, and fixing plus maintaining that may counter-balance the benefits.

How to Fix:

Tag matched methods with NDepend.Attributes.PureAttribute (from NDepend.API.dll), System.Diagnostics.Contracts.PureAttribute (honored by the compiler only with Microsoft Code Contract enabled), or your own attribute (adapting this query).

Record should be immutable

C#9 record is meant for value-based semantic: value-based equality and immutability, explained here: https://blog.ndepend.com/c9-records-immutable-classes/

A property setter not declared init still allows mutable state, which disrupts the value-based semantics: mutating a record used as a hash table key can corrupt the table, and equality results become unexpected — bugs difficult to spot and fix.

How to Fix:

Make the record immutable: transform mutable property setters (culpritSetters) into init property initializers, and refactor their callers (methodsCallingCulpritSetters) to stop changing record states.

Estimated Debt: 8 minutes plus 3 minutes per mutable setter and per method calling one.

Instance fields naming convention

Supports the 3 most used instance field naming conventions (adaptable to your own):

- name starting with a lower-case letter

- name starting with "_" followed by a lower-case letter

- name starting with "m_" followed by an upper-case letter

A static field behaves completely differently from an instance field, so differentiating them at a glance (e.g. m_ prefix) is valuable. Related discussion: https://blog.ndepend.com/on-hungarian-notation-for-fields-in-csharp/

How to Fix:

After adapting the rule to your naming convention, name all matched instance fields adequately.

Static fields naming convention

Supports the 3 most used static field naming conventions (adaptable to your own):

- name starting with an upper-case letter

- name starting with "_" followed by an upper-case letter

- name starting with "s_" followed by an upper-case letter

A static field behaves completely differently from an instance field, so differentiating them at a glance (e.g. s_ prefix) is valuable. Related discussion: https://blog.ndepend.com/on-hungarian-notation-for-fields-in-csharp/

How to Fix:

After adapting the rule to your naming convention, name all matched static fields adequately.

Interface name should begin with a 'I'

.NET interface names are commonly prefixed with an upper case I; this widely accepted convention is recommended. COM interfaces typically don't follow it, so interfaces tagged ComVisibleAttribute are not matched.

How to Fix:

Prefix matched interfaces names with an upper I.

Abstract base class should be suffixed with 'Base'

Warns about abstract classes not suffixed with Base, a common .NET practice. Only base classes deriving directly from System.Object are matched (not abstract classes in the middle of a hierarchy chain).

How to Fix:

Suffix the names of matched base classes with Base.

Exception class name should be suffixed with 'Exception'

Warns about exception classes not suffixed with Exception, a common .NET practice. ExceptionBase is also accepted for base classes.

How to Fix:

Suffix the names of matched exception classes with Exception.

Attribute class name should be suffixed with 'Attribute'

Warns about attribute classes not suffixed with Attribute, a common .NET practice.

How to Fix:

Suffix the names of matched attribute classes with Attribute.

Types name should begin with an Upper character

Warns about types whose names don't start with an Upper character. .NET commonly uses Pascal Casing Style (first letter of the identifier and of each concatenated word capitalized, e.g. BackColor).

How to Fix:

Pascal Case the names of matched types.

Methods name should begin with an Upper character

Warns about methods whose names don't start with an Upper character. .NET commonly uses Pascal Casing Style (first letter of the identifier and of each concatenated word capitalized, e.g. ComputeSize).

How to Fix:

Pascal Case the names of matched methods.

Do not name enum values 'Reserved'

An enum member named "Reserved" is presumably a placeholder to rename or remove later — a breaking change. Users can't be expected to ignore it or read documentation, and it causes confusion in object browsers and IDEs. Instead, add a new member in the future version: usually not a breaking change as long as original members' values don't change.

How to Fix:

Remove or rename the member.

Avoid types with name too long

Matches types with names longer than 40 characters: less readable, and possibly a sign the type does too much.

How to Fix:

Rename the type with a shorter name or split it into more fine-grained types.

Avoid methods with name too long

Matches methods with names longer than 40 characters: less readable, and possibly a sign the method does too much. Very expressive names are good practice for unit tests though, so test methods and methods of test classes are not matched.

How to Fix:

Rename the method with a shorter name equally conveying its behavior, or split it into smaller methods.

Avoid fields with name too long

Matches fields with names longer than 40 characters: less readable.

How to Fix:

Rename the field with a shorter name conveying the same information.

Avoid having different types with same name

Warns about multiple same-named types in different application or third-party namespaces or assemblies: confusion and naming collisions in source files using several of them.

How to Fix:

Rename concerned types.

Avoid prefixing type name with parent namespace name

Warns when the parent namespace name prefixes a contained type name (e.g. "RuntimeEnvironment" in namespace "Foo.Runtime" should be "Environment"): redundant naming without readability improvement. Types are not matched when several of them would end up with the same name once the prefix is removed (e.g. "MetricInfo" and "QualityGateInfo" both becoming "Info"). This rule doesn't warn about situations where two or more types end up with the same name.

How to Fix:

Remove the prefix from the type name.

Avoid naming types and namespaces with the same identifier

Warns when a type and a namespace share the same name (e.g. type Environment and namespace Foo.Environment): tedious compiler resolution collisions and less readable code.

How to Fix:

Rename the concerned type or namespace.

Don't call your method Dispose

The identifier Dispose should be kept for System.IDisposable implementations. Warns when a method named Dispose() belongs to a type not implementing System.IDisposable.

How to Fix:

Either implement System.IDisposable on the parent type, or rename the method, e.g. Close() Terminate() Finish() Quit() Exit() Unlock() ShutDown()…

Methods prefixed with 'Try' should return a boolean

A method prefixed with Try is expected to return a boolean (or Task<bool> if async) reflecting success or failure, usually with the result in an out parameter, e.g. System.Int32.TryParse(int,out string):bool

How to Fix:

Rename the method, or transform it into an operation that can fail.

Properties and fields that represent a collection of items should be named Items.

Properties and fields typed with a collection of items should be named with the plural form of Items (e.g. NewDirectories, Words, Values), for readability and predictability.

No warning when any word in the identifier ends with s (TasksToRun, KeysDisabled, ListOfElementsInResult… are valid), nor when the identifier contains Empty (common pattern for a shared immutable empty collection).

Collection types are those implementing IEnumerable<T>, except:

- Non generic types: rarely seen as collections (e.g. System.String implements IEnumerable<char> but strings are named like FirstName).

- Dictionaries: mappings rather than collections, commonly suffixed Map, Table or Dictionary (though names like PersonsByNames often satisfy this rule anyway).

How to Fix:

Rename by making plural the word best describing the items:

- ListOfDir can be renamed Directories.

- Children can be renamed ChildrenItems

- QueueForCache can be renamed QueueOfItemsForCache

DDD ubiquitous language check

Identifiers in the core domain should use the Domain Model language — the ubiquitous language of Domain Driven Design (DDD): naming rigor, since software doesn't cope well with ambiguity.

Disabled per default: customize the core domain namespace name and the domain terms list. Mention singular and plural forms both if needed (e.g. Seat and Seats); see also the related rule Properties and fields that represent a collection of items should be named Items.

Relies on the NDepend API extension method ExtensionMethodsString.GetWords(this string identifier) that smartly extracts terms from identifiers.

How to Fix:

The rule lists the words not in vocabulary per violation. Either rename the code element or add the missing term(s) to the vocabulary list in the rule source.

Avoid fields with same name in class hierarchy

Matches a field whose name is already used in the base class hierarchy. Compilers allow it (even when the base field is visible to derived classes), but it is likely an erroneous attempt to redefine a field.

How to Fix:

If the derived field is indeed a redefinition (same field type; for statics, a single instance suffices), delete it and make the base field protected. Otherwise rename the derived field, carefully renaming all its usages (they might relate to the base field).

Avoid various capitalizations for method name

Matches methods whose names differ only in capitalization (like ProcessOrderId vs ProcessOrderID). Choose a single capitalization application-wide for readability, maintainability and consistency.

Severity goes from Medium to Critical when various capitalizations occur within the same type: not just convention, it is error-prone — clients must investigate which version to call.

How to Fix:

Choose a single application-wide capitalization, or use method names that don't differ only by capitalization.

Debt is proportional to the number of capitalizations found (2 minimum).

Controller class name should be suffixed with 'Controller'

Warns about ASP.NET Controller classes not suffixed with Controller, a recommended practice: https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/actions ControllerBase is also accepted for base classes.

How to Fix:

Suffix the names of matched Controller classes with Controller.

Nested class members should not mask outer class' static members

The C# compiler lets nested class members share names with static members of the outer class, but this is discouraged: it can be unclear which member the inner class code references.

How to Fix:

Give inner class members unique and descriptive names.

Avoid referencing source file out of the project directory

Matches types whose source files are outside the Visual Studio project file's directory (and sub-directories). Such files, added via > Add > Existing Items… > Add As Link, share type definitions across assemblies, duplicating types at binary level: degraded maintainability and subtle versioning bugs.

Tolerable for some types shared across executables, e.g. startup concerns like assembly resolving handlers or .NET Framework version checks.

How to Fix:

Reference from a VS project only source files under the project file location. Severity is Low: more an advice than a problem.

Avoid duplicating a type definition across assemblies

Warns about sharing code across assemblies via linked source files (> Add > Existing Items… > Add As Link), duplicating types at binary level: degraded maintainability and subtle versioning bugs. Each match is a duplicated type; unfold typesDefs to see the definitions.

Tolerable for some types shared across executables, e.g. startup concerns like assembly resolving handlers or .NET Framework version checks.

How to Fix:

Share types through DLLs, or rename same-full-name types that differ.

Avoid defining multiple types in a source file

Multiple types in one source file decrease readability (developers expect one type per file in the Solution Explorer) and lead to files with too many lines. Each match is such a source file, indexed by one of its types (preferably the one named like the file).

Nested types, enumerations and file-visibility types are exempt: it is acceptable to declare them alongside their principal user type.

How to Fix:

Create a source file per type. Severity is Low: more an advice than a problem.

Namespace name should correspond to file location

The namespaces hierarchy should be synchronized with the source files directory hierarchy — a widely accepted convention; misalignment makes code less maintainable and harder to navigate. Matches namespaces whose source file locations don't align with the namespace name.

Comparisons are case-sensitive; the justACaseSensitiveIssue flag indicates a pure casing mismatch (slightly lower debt).

Source files out of the project directory are ignored: such linked files are shared across projects and already matched by the rule Avoid referencing source file out of the project directory.

How to Fix:

Align the namespace with the directory sub-paths containing the source files.

Types with source files stored in the same directory, should be declared in the same namespace

The namespaces hierarchy should be synchronized with the source files directory hierarchy — a widely accepted convention; misalignment makes code less maintainable and harder to navigate. Hence types with source files in the same directory should share the same namespace.

For each directory where most types are in one namespace (the main namespace) and a few are not, this rule matches the main namespace, typesOutOfMainNamespace (declared in the directory but outside it), and typesInMainNamespace (informational).

Source files out of the project directory are ignored: such linked files are shared across projects and already matched by the rule Avoid referencing source file out of the project directory.

How to Fix:

Violations are the types in typesOutOfMainNamespace. Typically such type…

- … is in the wrong namespace, right directory: move it to the main namespace.

- … is in the right namespace, wrong directory: move its source file to the proper namespace directory.

- … is declared in source files in different directories: prefer a single directory.

Estimated Debt: 2 minutes plus 5 minutes per type in typesOutOfMainNamespace.

Types declared in the same namespace, should have their source files stored in the same directory

The namespaces hierarchy should be synchronized with the source files directory hierarchy — a widely accepted convention; misalignment makes code less maintainable and harder to navigate. Hence types in the same namespace should have their source files in the same directory.

For each namespace with source files in several directories, the main directory is inferred (preferably the one named like the namespace). The rule matches the namespace, typesDeclaredOutOfMainDir (source files outside the main directory), the main directory, and typesDeclaredInMainDir (informational).

Source files out of the project directory are ignored: such linked files are shared across projects and already matched by the rule Avoid referencing source file out of the project directory.

How to Fix:

Violations are the types in typesDeclaredOutOfMainDir. Typically such type…

- … is in the wrong namespace, right directory: move it to the namespace corresponding to the parent directory.

- … is in the right namespace, wrong directory: move its source file to the main directory.

- … is declared in source files in different directories: prefer a single directory.

Estimated Debt: 2 minutes plus 5 minutes per type in typesDeclaredOutOfMainDir.

Mark ISerializable types with SerializableAttribute

The CLR recognizes types as serializable only when marked with SerializableAttribute, even with custom serialization via ISerializable. Matches ISerializable types not tagged with it.

How to Fix:

Tag the matched type with SerializableAttribute.

Mark assemblies with CLSCompliant (deprecated)

Deprecated, disabled by default; re-enable if it fits your environment.

The Common Language Specification (CLS) defines rules assemblies must follow for cross-language use. Assemblies should explicitly indicate CLS compliance with CLSCompliantAttribute (absent = not compliant); a compliant assembly may still contain non-compliant members. Matches assemblies not tagged with System.CLSCompliantAttribute.

How to Fix:

Tag the assembly with CLSCompliantAttribute. Rather than marking the whole assembly non-compliant, mark the specific non-compliant members, ideally providing CLS-compliant alternatives for the widest audience.

Mark assemblies with ComVisible (deprecated)

Deprecated, disabled by default; re-enable if it fits your environment.

ComVisibleAttribute determines how COM clients access managed code; assemblies should indicate COM visibility explicitly (absent = visible to COM clients), overridable per type and member. Matches assemblies not tagged with System.Runtime.InteropServices.ComVisibleAttribute.

How to Fix:

Tag the assembly with ComVisibleAttribute, value false if it shouldn't be visible to COM clients.

Mark attributes with AttributeUsageAttribute

Mark custom attributes with AttributeUsageAttribute to indicate where they can be applied, per their meaning (e.g. a type-maintainer attribute belongs on classes, enumerations and interfaces, not methods or properties). Valid targets come from the System.AttributeTargets enumeration; omitting the attribute means All targets.

Not matched: abstract attribute classes (usage can be deferred to derived classes) and classes whose base is tagged (usage is inherited).

How to Fix:

Specify targets via AttributeUsageAttribute with the proper AttributeTargets values.

Remove calls to GC.Collect()

Calling GC.Collect() directly can lead to performance issues. More: http://blogs.msdn.com/ricom/archive/2004/11/29/271829.aspx Matches methods calling any GC.Collect() overload.

How to Fix:

Remove matched calls to GC.Collect().

Don't call GC.Collect() without calling GC.WaitForPendingFinalizers()

Avoid direct GC.Collect() calls (see Remove calls to GC.Collect()). If you call it anyway, do:

GC.Collect();

GC.WaitForPendingFinalizers();

GC.Collect();

so finalizers execute and finalizable objects get cleaned properly. Matches methods calling GC.Collect() without GC.WaitForPendingFinalizers().

How to Fix:

If GC.Collect() is really needed, call GC.WaitForPendingFinalizers() properly.

Enum Storage should be Int32

Enumerations store constants as System.Int32 by default. Changing the underlying type is rarely necessary or recommended: smaller types bring no significant performance improvement. If needed, use CLS-compliant integral types (Byte, Int16, Int32, Int64). Matches enumerations whose underlying type is not System.Int32.

How to Fix:

Use Int32 unless size or compatibility issues exist; Int64 if values don't fit, Byte or Int16 if backward compatibility requires it.

Do not raise too general exception types

These exception types are too general to inform the user:

- System.Exception

- System.ApplicationException

- System.SystemException

Throwing them from a library compels clients to catch all exceptions, including unknown ones they can't handle. Matches methods instantiating such exceptions.

How to Fix:

Throw a more derived framework exception type, or your own type deriving from System.Exception.

Estimated Debt: 15 minutes per method plus 5 minutes per too general exception type instantiated.

Do not raise reserved exception types

These reserved exception types should be thrown only by the runtime:

- System.ExecutionEngineException

- System.IndexOutOfRangeException

- System.OutOfMemoryException

- System.StackOverflowException

- System.InvalidProgramException

- System.AccessViolationException

- System.CannotUnloadAppDomainException

- System.BadImageFormatException

- System.DataMisalignedException

Matches methods instantiating such reserved exceptions.

How to Fix:

Throw a specific non-reserved exception type instead.

For System.NullReferenceException, throw System.ArgumentNullException instead, or use a contract (MS Code Contracts or Debug.Assert()) meaning a null there can only be a bug. More generally, on detected corrupted state / bug consequence, a declarative assertion beats throwing: continuing is potentially harmful, the process should shut down and the failure be reported as a bug.

Uri fields or properties should be of type System.Uri

Fields and properties named ending with 'Uri' or 'Url' represent a Uniform Resource Identifier or Locator and should be typed System.Uri. Matches those that are not.

How to Fix:

Rename the field/property, or type it System.Uri. Severity is Low: more an advice than a problem.

Types should not derive from System.ApplicationException

Deriving exceptions from ApplicationException was recommended in .NET Framework 1; the recommendation is now to derive from System.Exception or one of its System namespace subclasses. Matches exception classes deriving from ApplicationException.

How to Fix:

Derive matched exception types from System.Exception or one of its System namespace subclasses.

Don't Implement ICloneable

System.ICloneable is a bad API: it predates generics, so Clone() returns an object needing a downcast; it doesn't say whether cloning is deep or shallow, a fundamental difference (https://stackoverflow.com/a/184745/27194); and classes deriving from an ICloneable implementer must implement Clone(), easy to forget.

Classes deriving from an ICloneable implementer are not matched: the fix belongs in the base class (maybe unfixable if third-party).

How to Fix:

Stop implementing this interface. Rename remaining Clone() methods to DeepClone() or ShallowClone() with typed results, or define IDeepCloneable<T> (DeepClone():T) and IShallowCloneable<T> (ShallowClone():T). Custom NDepend rules can enforce that derived classes override virtual clone methods.

Collection properties should be read only

A writable collection property lets users replace the whole collection; a read-only one still allows setting individual members. If replacement is needed, prefer clear and re-populate methods (see Clear() and AddRange() on System.Collections.Generic.List<T>).

Binary and XML serialization support read-only collection properties (XmlSerializer has specific requirements for ICollection / IEnumerable types). Matches property setters assigning a collection.

How to Fix:

Make the property read-only, adding clear and re-populate methods if the design requires it.

Don't use .NET 1.x HashTable and ArrayList

Deprecated, disabled by default; re-enable if it fits your environment. Warns about methods using non-generic collections: ArrayList, HashTable, Queue, Stack or SortedList.

How to Fix:

Prefer generic collections: strongly typed elements, faster with value types (no boxing):

- List<T> over ArrayList.

- Dictionary<K,V> over HashTable.

- Queue<T> over Queue.

- Stack<T> over Stack.

- SortedDictionary<K,V> or SortedList<K,V> over SortedList.

Being forced to use non-generic collections (third-party code, .NET 1.x) should question moving to newer .NET updates.

Caution with List.Contains()

Matches calls to List<T>.Contains(), an O(N) operation. For large lists or frequent calls, prefer System.Collections.Generic.HashSet<T> whose Contains() is constant time.

Not a rule: O(N) Contains() is usually not a mistake; this query just points out a potential performance pitfall.

Prefer return collection abstraction instead of implementation

Matches methods returning a collection implementation (List<T>, HashSet<T>, Dictionary<TKey,TValue>). Clients rarely need the exact implementation: prefer returning an interface like IList<T>, ICollection<T>, IEnumerable<T> or IDictionary<TKey,TValue>.

Not a rule, since the interface isn't preferable in all cases.

P/Invokes should be static and not be publicly visible

Methods marked DllImportAttribute (or VB Declare) access unmanaged code via Platform Invocation Services. Keep them private or internal so your library can't be used to breach security by giving callers access to unmanaged APIs. Matches DllImportAttribute methods declared public or non-static.

How to Fix:

Change the method's access level and/or declare it static.

Move P/Invokes to NativeMethods class

Platform Invocation methods (tagged DllImportAttribute or VB Declare) should be in one of these static internal classes with static internal methods:

- NativeMethods - no SuppressUnmanagedCodeSecurityAttribute: stack walks are performed, methods usable anywhere.

- SafeNativeMethods - SuppressUnmanagedCodeSecurityAttribute applied: harmless methods safe for anyone to call, no security review needed.

- UnsafeNativeMethods - SuppressUnmanagedCodeSecurityAttribute applied: potentially dangerous methods, callers must perform a full security review since no stack walk is performed.

Matches P/Invoke methods not declared in such classes.

How to Fix:

Move the method to the appropriate NativeMethods class; for most applications a new class named NativeMethods is enough.

NativeMethods class should be static and internal

As explained in Move P/Invokes to NativeMethods class, NativeMethods classes hosting P/Invoke methods should be static and internal. Warns about those that are not.

How to Fix:

Declare matched NativeMethods classes static and internal.

Don't create threads explicitly

Warns about methods instantiating System.Threading.Thread. Threads are costly (~200,000 cycles to create, ~100,000 to destroy, 1MB stack, 2,000-8,000 cycles per context switch): prefer letting the thread pool recycle threads.

How to Fix:

Use the Task Parallel Library (TPL), relying on the CLR thread pool, instead of creating threads. Introduction: https://msdn.microsoft.com/en-us/library/dd460717(v=vs.110).aspx TPL and the CLR v4 thread pool: http://www.danielmoth.com/Blog/New-And-Improved-CLR-4-Thread-Pool-Engine.aspx

Severity is Critical: creating threads can have severe consequences.

Don't use dangerous threading methods

Warns about Thread.Abort(), Sleep(), Suspend() and Resume():

- Thread.Abort() is dangerous: http://www.interact-sw.co.uk/iangblog/2004/11/12/cancellation

- Thread.Sleep() is a sign of flawed design: http://msmvps.com/blogs/peterritchie/archive/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program.aspx

- Suspend() and Resume() are dangerous and obsolete; workaround: http://stackoverflow.com/questions/382173/what-are-alternative-ways-to-suspend-and-resume-a-thread

How to Fix:

Suppress the calls listed in suppressCallsTo; use the Task Parallel Library (TPL) instead: https://msdn.microsoft.com/en-us/library/dd460717(v=vs.110).aspx

Monitor TryEnter/Exit must be both called within the same method

Warns when System.Threading.Monitor Enter()/TryEnter() and Exit() are not called within the same method: harder to locate where critical sections begin and end, and complex error-prone scenarios.

How to Fix:

Refactor so Monitor critical sections begin and end in the same method. Use the C# lock keyword for basic scenarios; explicit Monitor only for advanced ones needing Wait() and Pulse(). More: http://www.codeproject.com/Articles/13453/Practical-NET-and-C-Chapter

ReaderWriterLock AcquireLock/ReleaseLock must be both called within the same method

Warns when System.Threading.ReaderWriterLock acquire and release (reader or writer) methods are not called within the same method: harder to locate where critical sections begin and end, and complex error-prone scenarios.

How to Fix:

Refactor so ReaderWriterLock read or write critical sections begin and end in the same method.

Don't tag instance fields with ThreadStaticAttribute

Warns when System.ThreadStaticAttribute tags instance fields: per documentation it is exclusively for static fields. https://msdn.microsoft.com/en-us/library/system.threadstaticattribute

How to Fix:

Ensure all fields tagged ThreadStaticAttribute are static.

Method non-synchronized that read mutable states

Lists methods reading mutable state (modifiable instance or static fields) without synchronizing access — a potential state corruption in multi-threaded programs. Not a rule: most matches are not an issue.

Method should not return concrete XmlNode

Warns about methods returning System.Xml.XmlNode or a derived type. XmlNode implements System.Xml.Xpath.IXPathNavigable; returning the interface usually abstracts client code from implementation details.

How to Fix:

Return IXPathNavigable instead and refactor client code if possible.

Types should not derive from System.Xml.XmlDocument

Warns about subclasses of System.Xml.XmlDocument: don't subclass it to create an XML view of an underlying object model or data source.

How to Fix:

Use the System.Xml.XPath.IXPathNavigable interface implemented by XmlDocument, or use System.Xml.Linq.XDocument (LINQ2XML). More: http://stackoverflow.com/questions/1542073/xdocument-or-xmldocument

Float and Date Parsing must be culture aware

Warns about non-globalized overloads (without an IFormatProvider parameter) of Parse(), TryParse() and ToString() on DateTime, float, double and decimal — a symptom that the application supporting localized UIs and regional data is at least partially not globalized.

How to Fix:

Use the globalized overloads; culprit callers are listed in MethodsCallingMe. More on Creating Globally Aware Applications: https://msdn.microsoft.com/en-us/library/cc853414(VS.95).aspx

Estimated Debt: 5 minutes per method calling a non-culture aware method, plus 3 minutes per non-culture aware method called.

Mark assemblies with assembly version

An assembly identity is: name, version number, culture, public key (if strong-named). .NET uses the version to uniquely identify an assembly and bind to types in strong-named assemblies; by default applications only run with the version they were built with. Matches assemblies not tagged with System.Reflection.AssemblyVersionAttribute.

How to Fix:

Add a version via System.Reflection.AssemblyVersionAttribute.

Assemblies should have the same version

Reports assemblies whose version differs from the one shared by most application assemblies. Double check first whether multiple versions are legitimate — typically when assemblies are not compiled, developed or deployed together.

How to Fix:

Use System.Reflection.AssemblyVersion in a source file shared by the assemblies, typically generated by a dedicated MSBuild task like: http://www.msbuildextensionpack.com/help/4.0.5.0/html/d6c3b5e8-00d4-c826-1a73-3cfe637f3827.htm. Versioning advices: http://stackoverflow.com/a/3905443/27194

Severity is major: improper versioning can lead to complicated deployment problems.

Assemblies Referenced in Multiple Versions

Detects third-party assemblies referenced in multiple versions, which can cause unexpected behavior and bugs. The issue explanation lists the application and third-party assemblies referencing the different versions; the scan is transitive.

How to Fix:

Reference each package in a single version via Transitive pinning in Central Package Management: set CentralPackageTransitivePinningEnabled to true in a Directory.Packages.props or Directory.Build.props import file. More: https://blog.ndepend.com/understand-nuget-central-package-management-and-transitive-pinning-with-examples/

Pinning aligns the versions your projects restore and compile against, but it cannot change a reference compiled into a third-party package: when the issue explanation lists a third-party assembly that uses the older version, the issue remains after pinning. Upgrade that package to a release built against the newer version, or remove it if your code barely uses it.

If pinning breaks the restore with a package downgrade error (NU1109), raise the central version of the package named in the error to a stable release that satisfies the graph, or leave pinning off. Never raise it to a prerelease.

Public methods returning a reference needs a contract to ensure that a non-null reference is returned

Code Contracts decrease caller/callee ambiguity; not ensuring a returned reference is non-null leaves ambiguity. Matches methods returning a reference type without using Contract.Ensure() (from Microsoft Code Contracts for .NET), typically: Contract.Ensures(Contract.Result<ReturnType>() != null, "returned reference is not null"); https://visualstudiogallery.msdn.microsoft.com/1ec7db13-3363-46c9-851f-1ce455f66970

How to Fix:

Use Microsoft Code Contracts for .NET on your API's public surface to remove null / not null ambiguities. For methods that might not return a result, prefer the TryXXX() pattern (like System.Int32.TryParse()) over returning null.

Estimated Debt: 5 minutes per method possibly returning null plus 3 minutes per caller.

Classes tagged with InitializeOnLoad should have a static constructor

InitializeOnLoadAttribute initializes an Editor class when Unity loads and when scripts are recompiled; the tagged class's static constructor is responsible for the initialization.

How to Fix:

Create a static constructor for the matched classes.

Avoid using non-generic GetComponent

Prefer using the generic version of Component.GetComponent() for type safety.

How to Fix:

Refactor GetComponent(typeof(MyType)) calls in GetComponent<MyType>().

Avoid empty Unity message

Unity messages are called by the runtime even if they don't contain any code.

How to Fix:

Remove matched methods to avoid unnecessary processing.

Avoid using Time.fixedDeltaTime with Update

Update() and FixedUpdate() depend on the frame rate. Use Time.deltaTime instead of Time.fixedDeltaTime: it automatically returns the right delta time inside these functions.

How to Fix:

Replace Time.fixedDeltaTime with Time.deltaTime within Update() and FixedUpdate().

Use CreateInstance to create a scriptable object

Instances of types deriving from UnityEngine.ScriptableObject must be created via ScriptableObject.CreateInstance<T>(): the Unity engine needs to create the object itself to handle Unity message methods.

How to Fix:

Replace new Foo() expressions with ScriptableObject.CreateInstance<Foo>() expressions.

The SerializeField attribute is redundant on public fields

SerializeField makes a field display in the Inspector and be saved — which declaring the field public already does. Hence the attribute is redundant on public fields.

How to Fix:

Remove the SerializeField attribute on matched public fields.

InitializeOnLoadMethod should tag only static and parameterless methods

InitializeOnLoadMethodAttribute initializes an editor static method when Unity loads; RuntimeInitializeOnLoadMethodAttribute does the same after the game has loaded. Both can only tag static parameterless methods.

How to Fix:

Make the matched methods static and parameterless.

Prefer using SetPixels32() over SetPixels()

Color uses floating point [0.0,1.0] per component; Color32 uses a byte [0,255]: 4 times less memory and much faster to work with.

How to Fix:

If 32bit-RGBA is compatible with your scenario, use SetPixels32() instead.

Don't use System.Reflection in performance critical messages

System.Reflection is slow: don't use it in performance critical messages like Update, FixedUpdate, LateUpdate, or OnGUI.

How to Fix:

Don't use reflection in matched methods.

New assemblies

Runs only in diff mode (baseline defined). Lists assemblies added since the baseline.

Assemblies removed

Runs only in diff mode (baseline defined). Lists assemblies removed since the baseline.

Assemblies where code was changed

Runs only in diff mode (baseline defined). Lists assemblies whose code changed since the baseline.

New namespaces

Runs only in diff mode (baseline defined). Lists namespaces added since the baseline.

Namespaces removed

Runs only in diff mode (baseline defined). Lists namespaces removed since the baseline.

Namespaces where code was changed

Runs only in diff mode (baseline defined). Lists namespaces whose code changed since the baseline.

New types

Runs only in diff mode (baseline defined). Lists types added since the baseline.

Types removed

Runs only in diff mode (baseline defined). Lists types removed since the baseline.

Types where code was changed

Runs only in diff mode (baseline defined). Lists types whose code changed since the baseline.

To visualize changes, right-click a matched type and select:

- Compare older and newer versions of source file

- Compare older and newer versions decompiled with Reflector

Heuristic to find types moved from one namespace or assembly to another

Runs only in diff mode (baseline defined). Lists types moved between namespaces or assemblies, via a join LINQ query on type name (without namespace prefix) over the types added and removed sets.

Types directly using one or several types changed

Runs only in diff mode (baseline defined). Lists unchanged types directly using types whose code changed since the baseline: their code didn't change but their behavior might have. The result includes the changed types used.

Types indirectly using one or several types changed

Runs only in diff mode (baseline defined). Lists unchanged types using directly or indirectly types whose code changed since the baseline: their code didn't change but their behavior might have. The result includes the changed types directly used and the depth of usage, as defined for the DepthOfIsUsingAny() NDepend API method: https://www.ndepend.com/api/NDepend.CodeModel.ExtensionMethodsSequenceUsage.html#NDepend_CodeModel_ExtensionMethodsSequenceUsage_DepthOfIsUsingAny__2_System_Collections_Generic_IEnumerable___0__System_Collections_Generic_IEnumerable___1__

New methods

Runs only in diff mode (baseline defined). Lists methods added since the baseline.

Methods removed

Runs only in diff mode (baseline defined). Lists methods removed since the baseline.

Methods where code was changed

Runs only in diff mode (baseline defined). Lists methods whose code changed since the baseline.

To visualize changes, right-click a matched method and select:

- Compare older and newer versions of source file

- Compare older and newer versions decompiled with Reflector

Methods directly calling one or several methods changed

Runs only in diff mode (baseline defined). Lists unchanged methods directly calling methods whose code changed since the baseline: their code didn't change but their behavior might have. The result includes the changed methods called.

Methods indirectly calling one or several methods changed

Runs only in diff mode (baseline defined). Lists unchanged methods using directly or indirectly methods whose code changed since the baseline: their code didn't change but their behavior might have. The result includes the changed methods directly used and the depth of usage, as defined for the DepthOfIsUsingAny() NDepend API method: https://www.ndepend.com/api/NDepend.CodeModel.ExtensionMethodsSequenceUsage.html#NDepend_CodeModel_ExtensionMethodsSequenceUsage_DepthOfIsUsingAny__2_System_Collections_Generic_IEnumerable___0__System_Collections_Generic_IEnumerable___1__

New fields

Runs only in diff mode (baseline defined). Lists fields added since the baseline.

Fields removed

Runs only in diff mode (baseline defined). Lists fields removed since the baseline.

Third party types that were not used and that are now used

Runs only in diff mode (baseline defined). Lists third-party types not used at baseline time and now used.

Third party types that were used and that are not used anymore

Runs only in diff mode (baseline defined). Lists third-party types used at baseline time and no longer used.

Third party methods that were not used and that are now used

Runs only in diff mode (baseline defined). Lists third-party methods not used at baseline time and now used.

Third party methods that were used and that are not used anymore

Runs only in diff mode (baseline defined). Lists third-party methods used at baseline time and no longer used.

Third party fields that were not used and that are now used

Runs only in diff mode (baseline defined). Lists third-party fields not used at baseline time and now used.

Third party fields that were used and that are not used anymore

Runs only in diff mode (baseline defined). Lists third-party fields used at baseline time and no longer used.

Check that the assembly Asm1 is not using the assembly Asm2

A sample rule to adapt to your need: warns if a particular assembly uses another particular assembly.

Generate such a rule for assemblies A and B by right-clicking the Dependency Matrix cell (B in row, A in column) or the Dependency Graph arrow from A to B, then clicking Generate a code rule that warns if this dependency exists. Adapt the generated rule to your needs.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that the namespace N1.N2 is not using the namespace N3.N4.N5

A sample rule to adapt to your need: warns if a particular namespace uses another particular namespace.

Generate such a rule for namespaces A and B by right-clicking the Dependency Matrix cell (B in row, A in column) or the Dependency Graph arrow from A to B, then clicking Generate a code rule that warns if this dependency exists. Adapt the generated rule to your needs.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that the assembly Asm1 is only using the assemblies Asm2, Asm3 or System.Runtime

A sample rule to adapt to your need: enforces that a particular assembly is only using a particular set of assemblies.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that the namespace N1.N2 is only using the namespaces N3.N4, N5 or System

A sample rule to adapt to your need: enforces that a particular namespace is only using a particular set of namespaces.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that AsmABC is the only assembly that is using System.Collections.Concurrent

A sample rule to adapt to your need: enforces that a particular assembly is only used by another particular assembly.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that only 3 assemblies are using System.Collections.Concurrent

A sample rule to adapt to your need: enforces that a particular assembly is only used by any 3 other assemblies.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that all methods that call Foo.Fct1() also call Foo.Fct2(Int32)

A sample rule to adapt to your need: enforces that a method calling a particular method must also call another particular method.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that all types that derive from Foo, also implement IFoo

A sample rule to adapt to your need: enforces that all classes deriving from a particular base class also implement a particular interface.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that all types that has the attribute FooAttribute are declared in the namespace N1.N2*

A sample rule to adapt to your need: enforces that all types tagged with a particular attribute are declared in a particular namespace.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that all synchronization objects are only used from the namespaces under MyNamespace.Sync

A sample rule to adapt to your need: enforces that all synchronization objects are used from a particular namespace.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that the namespace N1.N2 is 100% covered by tests

A sample rule checking that a particular namespace is 100% covered by tests; adapt @"N1.N2" and the threshold 100. Requires coverage data imported: https://www.ndepend.com/docs/code-coverage

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that the assembly Asm is 100% covered by tests

A sample rule checking that a particular assembly is 100% covered by tests; adapt @"Asm" and the threshold 100. Requires coverage data imported: https://www.ndepend.com/docs/code-coverage

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that the class Namespace.Foo is 100% covered by tests

A sample rule checking that a particular class is 100% covered by tests; adapt @"Namespace.Foo" and the threshold 100. Requires coverage data imported: https://www.ndepend.com/docs/code-coverage

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that the method Namespace.Foo.Method(Int32) is 100% covered by tests

A sample rule checking that a particular method is 100% covered by tests; adapt @"Namespace.Foo.Method(Int32)" and the threshold 100. Requires coverage data imported: https://www.ndepend.com/docs/code-coverage

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that all types that derive from Foo, has a name that ends up with Foo

A sample rule to adapt to your need: enforces that all classes deriving from a particular class are named with a particular suffix.

How to Fix:

This is a sample rule, there is nothing to fix as is.

Check that all namespaces begins with CompanyName.ProductName

A widely adopted practice: all namespaces of a product start with "CompanyName.ProductName". Adapt the rule with your own "CompanyName.ProductName".

How to Fix:

Update all namespaces definitions in source code to satisfy this rule.