Nomenclature Rules

Capitalization Rules

1. The PascalCasing convention, used for all identifiers except parameter names, capitalizes the first character of each word (including acronyms over two letters in length), as shown in the following examples:

                PropertyDescriptor HtmlTag

                DO use PascalCasing for

• Namespace
• Type
• Interface
• Method
• Property
• Event
• Field
• Enum value

1.  The camelCasing convention, used only for parameter names, capitalizes the first character of each word except the first word, as shown in the following examples. As the example also shows, two-letter acronyms that begin a camel-cased identifier are both lowercase.

        propertyDescriptor ioStream htmlTag

        DO use camelCasing for parameter names.

Case Sensitivity

DO NOT assume that all programming languages are case sensitive. They are not. Names cannot differ by case alone.

Word Choice

1. DO choose easily readable identifier names.
   For example, a property named HorizontalAlignment is more English-readable than AlignmentHorizontal.
2.  DO NOT use underscores, hyphens, or any other nonalphanumeric characters.
3. DO NOT use Hungarian notation.
4.  AVOID using identifiers that conflict with keywords of widely used programming languages.

 Using Abbreviations and acronyms

1. DO NOT use abbreviations or contractions as part of identifier names.
   For example, use GetWindow rather than GetWin.
2. X DO NOT use any acronyms that are not widely accepted, and even if they are, only when necessary.

Avoid Language Specific Names

1. DO use semantically interesting names rather than language-specific keywords for type names.
   For example, GetLength is a better name than GetInt.
2. DO use a generic CLR type name, rather than a language-specific name, in the rare cases when an identifier has no semantic meaning beyond its type.

Names of Classes, Structs, and Interfaces

1. DO name classes and structs with nouns or noun phrases, using PascalCasing.
2. DO name interfaces with adjective phrases, or occasionally with nouns or noun phrases.
3. DO NOT give class names a prefix (e.g., "C").
4. CONSIDER ending the name of derived classes with the name of the base class.
5. DO prefix interface names with the letter I, to indicate that the type is an interface.
6. DO ensure that the names differ only by the "I" prefix on the interface name when you are defining a class–interface pair where the class is a standard implementation of the interface.