Edit

Maintainability rules

  • Article

Maintainability rules support library and application maintenance.

In this section

Rule Description
CA1501: Avoid excessive inheritance A type is more than four levels deep in its inheritance hierarchy. Deeply nested type hierarchies can be difficult to follow, understand, and maintain.
CA1502: Avoid excessive complexity This rule measures the number of linearly independent paths through the method, which is determined by the number and complexity of conditional branches.
CA1505: Avoid unmaintainable code A type or method has a low maintainability index value. A low maintainability index indicates that a type or method is probably difficult to maintain and would be a good candidate for redesign.
CA1506: Avoid excessive class coupling This rule measures class coupling by counting the number of unique type references that a type or method contains.
CA1507: Use nameof in place of string A string literal is used as an argument where a nameof expression could be used.
CA1508: Avoid dead conditional code A method has conditional code that always evaluates to true or false at run time. This leads to dead code in the false branch of the condition.
CA1509: Invalid entry in code metrics configuration file Code metrics rules, such as CA1501, CA1502, CA1505 and CA1506, supplied a configuration file named CodeMetricsConfig.txt that has an invalid entry.
CA1510: Use ArgumentNullException throw helper Throw helpers are simpler and more efficient than if blocks that construct a new exception instance.
CA1511: Use ArgumentException throw helper Throw helpers are simpler and more efficient than if blocks that construct a new exception instance.
CA1512: Use ArgumentOutOfRangeException throw helper Throw helpers are simpler and more efficient than if blocks that construct a new exception instance.
CA1513: Use ObjectDisposedException throw helper Throw helpers are simpler and more efficient than if blocks that construct a new exception instance.
CA1514: Avoid redundant length argument A redundant length argument is used when slicing to the end of a string or buffer. A calculated length can be error-prone and is also unnecessary.
CA1515: Consider making public types internal Unlike a class library, an application's API isn't typically referenced publicly, so types can be marked internal.

See also