". NET Specification" 3rd Chapter naming specification

The. NET specification, chapter 3rd naming specification 3.1 casing conventions

To use PascalCasing for namespaces, types, and names of members that consist of multiple words.

To use camelCasing for the name of the parameter.

To capitalize all two-letter acronyms unless it is the first word of the camelCasing style parameter name.

Capitalize the first letter of an acronym consisting of three or more than three letters. Only the first letter is capitalized, unless the acronym is the first word of the camelCasing style identifier.

Do not capitalize any of the initials of any acronym in the CamelCasing style identifier header, regardless of the length of the acronym.

Do not capitalize the first letter of each word in the so-called closed form of a compound.

Do not assume that all programming languages are case-sensitive, and this is not the case. You should not distinguish names by case by case only.

　　

3.2 General Naming conventions

To select an easy-to-read name for the identifier.

Instead of focusing more on brevity, you need to focus more on readability.

Do not use underscores, hyphens, and any other characters that are not alphanumeric.

Do not use Hungarian nomenclature.

Avoid conflicting identifiers with keywords that are widely used in programming languages.

Do not use abbreviations and acronyms as part of the identifier name. For example, to use GetWindow instead of Getwin.

Do not use acronyms that are not widely accepted, even if they are widely accepted acronyms, and should only be used when necessary.

To give a type name a meaningful name, instead of using a language-specific keyword.

To use the CLR's generic type name instead of using a language-specific alias-if the identifier has no other semantics other than the type.

To use a common name, such as value or item, rather than repeating the name of the type-if the identifier has no other semantics other than the type, the type of the parameter does not matter.

Use a name similar to the old API to create a new version of an existing API.

Use suffixes instead of prefixes to represent new versions of existing APIs.

Consider using a new but meaningful identifier instead of simply adding a suffix or prefix to an existing identifier.

To use a numeric suffix to represent a new version of an existing API-if the name of an existing API is the only meaningful name (that is, it is an industry standard), it is not appropriate to add a suffix (or rename).

Do not use "Ex" (or similar) suffixes in identifiers to differentiate between different versions of the same API.

Use the "64" suffix to introduce a new version of the APi that operates on a 64-bit integer (long) instead of a 32-bit integer. This is only required if there is already a 32-bit API, which is not required for a new API with only 64-bit versions.

　　

3.3 Naming of assemblies and DLLs

3.4 Naming of namespaces

Use the company name as a prefix to the namespace so you can avoid using the same name as other companies.

Use a stable, version-independent product name as the second level of the namespace.

Do not determine the hierarchy of namespaces based on your company's organizational structure, because the names of organizations within a company may change over time.

To use the PascalCasing case style, separate the parts of the namespace with a dot number. If the trademark uses a non-traditional case style, then even if the style is inconsistent with the normal case style, it should follow the trademark's case style.

Consider using the plural form in the namespace, as appropriate.

Do not use the same name for naming namespaces and the types that are located in that namespace.

Do not introduce a type name that is too generalized, such as Element, Node, Log, and Message.

Do not give the type a name that conflicts with any type in the core namespace.

Do not give types a name that conflicts with other types in the same technology.

Do not introduce a type name conflict between the technology namespace and the type of the application model namespace (unless you intend to use the technology with the application model).

　　

3.5 Naming of classes, structs, and interfaces

Use nouns or noun phrases to name classes and structs. Use the pascalcasing capitalization style when naming. This separates the type name from the method area, which is named by the verb phrase.

To name an interface with an adjective phrase, a noun or noun phrase can be used in a few cases.

Do not prefix the class name.

Consider using the name of the base class at the end of the derived class.

To have the name of the interface begin with the letter I, it shows that the type is an interface.

Make sure that the name of a pair of classes/interfaces is only one "I" prefix if the class is a standard implementation of that interface.

To name a generic type parameter with a descriptive name-unless a single letter can explain the meaning without using a descriptive name.

Consider naming the parameter type with a single letter T-if the type has only one type parameter and the type argument has only one letter.

To add a T prefix to a descriptive type parameter name.

Consider displaying a constraint on a type parameter name that is applied to that type argument.

Follow the specifications described-if you want to derive a new class from a type of. NET Framework, or to implement a type in the. NET Framework.

To name an enumeration type with a singular noun, unless it represents a bit field.

To use a plural noun to name an enumeration type that represents a bit field, the enumeration type becomes a tag enumeration.

Do not add an "enum" suffix to an enum type without a name.

Do not add "Flag" or "flags" suffix to the name of the enumeration type.

Do not prefix the names of enumerated type values.

3.6 Naming of type members

Use a noun, noun phrase, or adjective to name the attribute.

Do not let the property name appear similar to the name of the "Get" method.

Instead of using the singular form of a phrase to add a "List" or "Collection" suffix, use the plural form of the item phrase in the Description collection to name the collection property.

Use a positive phrase (CanSeek instead of Cantseek) to name the Boolean attribute. If it is helpful, you can optionally add a prefix such as "is", "can" or "has" to the Boolean attribute.

Consider naming the property with the type name of the property.

Use a verb or verb phrase to name the event.

Use current and past to give the concept before and after the event name.

Do not use the "before" and "after" prefixes or suffixes to differentiate between pre-events and post-events.

To add a "EventHandler" suffix to the named event handler function, which is used as the delegate for the event type.

To use sender and E as the name of the two parameter in the event handler function.

To add the "EventArgs" suffix to the parameter class of the named event.

To use the PascalCasing case style when naming fields.

Use a noun, noun phrase, or adjective to name the field.

Do not prefix field names.

3.7 Naming of parameters

To use the camelCasing casing style when naming parameters.

To use a descriptive parameter name.

Consider naming parameters based on the meaning of the parameter rather than the type of the parameter.

To use left and right to name parameters that overload the two-tuple operator-if the parameter does not have a specific meaning.

To use value to name parameters that overload the unary operator-if the parameter does not have a specific meaning.

Consider using meaningful names to name the parameters of the overloaded operator-if you do so, you can clearly express the meaning of the name.

Do not use abbreviations or numeric numbers when naming arguments for overloaded operators.

　　

3.8 Naming of resources

To use the pascalcasing capitalization style when naming resource keys.

To make the name of an identifier descriptive rather than make the name shorter.

Do not use keywords that are unique to each major CLR programming language.

To use only letters, numbers, and underscores when naming resources.

The following naming convention is to be followed in order to name the resource of the exception message.

　　

"Provenance" http://www.cnblogs.com/liqingwen/p/7152673.html

". NET Specification" 3rd Chapter naming specification