Microsoft Extended Design Guideline Rules Code Analysis Rule Set

The Microsoft Extended Design Guideline Rules rule set expands on the basic design guideline rules to maximize the usability and maintainability issues that are reported. Extra emphasis is placed on naming guidelines. You should consider including this rule set if your project includes library code or if you want to enforce the highest standards for writing code that is easy to maintain.

The Extended Design Guideline Rules include all of the Microsoft Basic Design Guideline Rules. The Basic Design Guideline Rules include all of the Microsoft Minimum Recommended Rules. For more information, see Microsoft Basic Design Guideline Rules Code Analysis Rule Set and Microsoft Minimum Recommended Rules Code Analysis Rule Set

The following table describes all the rules in the Microsoft Extended Design Guideline Rules rule set.

Rule	Description
CA1020: Avoid namespaces with few types	Make sure that there is a logical organization to each of your namespaces, and that there is a valid reason for putting types in a sparsely populated namespace.
CA1021: Avoid out parameters	Passing types by reference (using out or ref) requires experience with pointers, understanding how value types and reference types differ, and handling methods with multiple return values. Also, the difference between out and ref parameters is not widely understood.
CA1040: Avoid empty interfaces	Interfaces define members that provide a behavior or usage contract. The functionality described by the interface can be adopted by any type, regardless of where the type appears in the inheritance hierarchy. A type implements an interface by providing implementations for the interface's members. An empty interface does not define any members; therefore, it does not define a contract that can be implemented.
CA1045: Do not pass types by reference	Passing types by reference (using out or ref) requires experience with pointers, understanding how value types and reference types differ, and handling methods with multiple return values. Library architects who design for a general audience should not expect users to master working with out or ref parameters.
CA1062: Validate arguments of public methods	All reference arguments passed to externally visible methods should be checked against null.
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.
CA1504: Review misleading field names	The name of an instance field starts with "s_", or the name of a static (Shared in Visual Basic) field starts with "m_".
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.
CA1700: Do not name enum values 'Reserved'	This rule assumes that an enumeration member with a name that contains "reserved" is not currently used but is a placeholder to be renamed or removed in a future version. Renaming or removing a member is a breaking change.
CA1701: Resource string compound words should be cased correctly	Each word in the resource string is split into tokens based on the casing. Each contiguous two-token combination is checked by the Microsoft spelling checker library. If recognized, the word produces a violation of the rule.
CA1702: Compound words should be cased correctly	The name of an identifier contains multiple words, and at least one of the words appears to be a compound word that is not cased correctly.
CA1703: Resource strings should be spelled correctly	A resource string contains one or more words that are not recognized by the Microsoft spelling checker library.
CA1704: Identifiers should be spelled correctly	The name of an externally visible identifier contains one or more words that are not recognized by the Microsoft spelling checker library.
CA1707: Identifiers should not contain underscores	By convention, identifier names do not contain the underscore (_) character. This rule checks namespaces, types, members, and parameters.
CA1709: Identifiers should be cased correctly	By convention, parameter names use camel casing, while namespace, type, and member names use Pascal casing.
CA1710: Identifiers should have correct suffix	By convention, the names of types that extend certain base types or that implement certain interfaces, or types derived from these types, have a suffix that is associated with the base type or interface.
CA1711: Identifiers should not have incorrect suffix	By convention, only the names of types that extend certain base types or that implement certain interfaces, or types derived from these types, should end with specific reserved suffixes. Other type names should not use these reserved suffixes.
CA1712: Do not prefix enum values with type name	Names of enumeration members are not prefixed with the type name because type information is expected to be provided by development tools.
CA1713: Events should not have before or after prefix	The name of an event starts with "Before" or "After". To name related events that are raised in a specific sequence, use the present or past tense to indicate the relative position in the sequence of actions.
CA1714: Flags enums should have plural names	A public enumeration has the System.FlagsAttribute attribute, and its name does not end in "s". Types marked with FlagsAttribute have names that are plural because the attribute indicates that more than one value can be specified.
CA1715: Identifiers should have correct prefix	The name of an externally visible interface does not start with a capital "I". The name of a generic type parameter on an externally visible type or method does not start with a capital "T".
CA1717: Only FlagsAttribute enums should have plural names	Naming conventions dictate that a plural name for an enumeration indicates that more than one value of the enumeration can be specified at the same time.
CA1719: Parameter names should not match member names	A parameter name should communicate a parameter's meaning, and a member name should communicate a member's meaning. It would be a rare design where these were the same. Naming a parameter the same as its member name is unintuitive and makes the library difficult to use.
CA1720: Identifiers should not contain type names	The name of a parameter in an externally visible member contains a data type name, or the name of an externally visible member contains a language-specific data type name.
CA1721: Property names should not match get methods	The name of a public or protected member starts with "Get" and otherwise matches the name of a public or protected property. "Get" methods and properties should have names that clearly distinguish their function.
CA1722: Identifiers should not have incorrect prefix	By convention, only certain programming elements have names that begin with a specific prefix.
CA1724: Type Names Should Not Match Namespaces	Type names should not match the names of namespaces defined in the .NET Framework class library. Violating this rule can reduce the usability of the library.
CA1725: Parameter names should match base declaration	Consistent naming of parameters in an override hierarchy increases the usability of the method overrides. A parameter name in a derived method that differs from the name in the base declaration can cause confusion about whether the method is an override of the base method or a new overload of the method.
CA1726: Use preferred terms	The name of an externally visible identifier includes a term for which an alternative, preferred term exists. Alternatively, the name includes the term "Flag" or "Flags".
CA2204: Literals should be spelled correctly	A literal string in a method body contains one or more words that are not recognized by the Microsoft spelling checker library.