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 |
|---|---|
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. |
|
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. |
|
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. |
|
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. |
|
All reference arguments passed to externally visible methods should be checked against null. |
|
A type is more than four levels deep in its inheritance hierarchy. Deeply nested type hierarchies can be difficult to follow, understand, and maintain. |
|
The name of an instance field starts with "s_", or the name of a static (Shared in Visual Basic) field starts with "m_". |
|
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. |
|
This rule measures class coupling by counting the number of unique type references that a type or method contains. |
|
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. |
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. |
|
A resource string contains one or more words that are not recognized by the Microsoft spelling checker library. |
|
The name of an externally visible identifier contains one or more words that are not recognized by the Microsoft spelling checker library. |
|
By convention, identifier names do not contain the underscore (_) character. This rule checks namespaces, types, members, and parameters. |
|
By convention, parameter names use camel casing, while namespace, type, and member names use Pascal casing. |
|
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. |
|
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. |
|
Names of enumeration members are not prefixed with the type name because type information is expected to be provided by development tools. |
|
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. |
|
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. |
|
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". |
|
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. |
|
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. |
|
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. |
|
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. |
|
By convention, only certain programming elements have names that begin with a specific prefix. |
|
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. |
|
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. |
|
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". |
|
A literal string in a method body contains one or more words that are not recognized by the Microsoft spelling checker library. |