. NET naming conventions

The naming conventions are followed primarily for the developer to be easy to understand and maintain consistency with the framework elements.

• Casing conventions

Casing rules for identifiers: In order to differentiate multiple words in an identifier, capitalize the first letter of each word in the identifier. Do not underline, or use underscores anywhere in the identifier. Generally two kinds of ways: pascalcasing Pascal, CamelCasing hump

The PascalCasing convention is used for all identifiers except parameter names, which capitalize the first letter of each word in the identifier (including acronyms longer than two characters), such as: Peopertydescriptor, Htmltag

Two or more acronyms should be capitalized, such as Rbgconnection, IOStream.

Camelcasing is used only for the name of the parameter, it capitalizes the first letter of the identifier except the first word, and if the first letter is an abbreviation, it is lowercase, such as: htmltag,rbgconnection; for camelcasing parameters, no matter how long the acronym IS, Do not use uppercase for (closed form) compound words to be regarded as a word, such as endpoint, headfirst, Something, anyone, and so on.

• Universal Naming conventions

The choice of words should focus on easy-to-read names, readability, rather than brevity (Hungarian nomenclature).

Hungarian naming: Use lowercase data types as prefixes for variables, such as Uicount, and the other is to prefix the variable names to represent scopes. Cons: A custom data type that the developer cannot find some meaningful consistency in the prefix. Try not to use abbreviations and acronyms as part of the identifier name, but it can also be used for acronyms that are well known to everyone, such as UI (User Interface), HTML (Hyertext markup Language).

Avoid using name-specific names for the type names, rather than using language-specific keywords, such as getlength, which is better than Getint, and using CLR-generic types instead of using unique aliases such as ToInt64 instead of Tolong .

For the new version of the existing API name, to be as similar as the old, preferred to use suffixes instead of prefixes, in favor of smart hints when the two API can be in one piece. If the name of the API is the only meaningful name (industry standard), you can use a number as a suffix, or enable a new name. For the API version of the difference, it is best not to use the ex suffix.

• Naming of assemblies and DLLs

Namespaces (namespace) and DLLs are not the same thing. A DLL may have more than one namespace name, preferably a representative name for the DLL assembly, or it can be in the following format:

<company>.<component>.dll

Name of namespace Template: <company>. (<Product>|<Technology>) [. <feature>] [. <subnamespace>]

• Classes, structs, and interfaces

Classes and structures should be nouns or noun phrases, which should represent the entities in the system, and if the interface represents the root of a type hierarchy, then it should be a noun or noun phrase, or, if it represents a certain ability, an adjective or adjective phrase, such as icomparable<t>.

For derived classes of a class, the base class can be used as a suffix, and the interface is usually prefixed with "I".

For parameters of a generic class, if there is only one argument, you can use the "T" letter, or you can precede the parameter name with "T".

• Common types of naming

Enumeration types are generally represented by words, and it is best to use plural nouns for bit field type enumerations (Tag enumerations).

Methods, events generally use verbs or verb phrases; Avoid custom event handlers as much as possible, and most APIs can use eventhandler<t> directly.

attribute to use a noun or an adjective, for a set attribute, you should use a complex number; You can name a property with a type name, for example:

The above content is summarized in the. NET design Specification "

. NET naming conventions