Chapter 2 naming rules of. NET specification and. net Specification

Chapter 2 naming rules of. NET specification and. net Specification
. NET specification Chapter 1 naming convention

3.1 case sensitivity

PascalCasing should be used for the namespace, type, and member name composed of multiple words.

Use camelCasing as the parameter name.

The first letter of the two letters should be capitalized unless it is the first word of the parameter name in the camelCasing style.

The first letter of an acronym consisting of three or more letters should be capitalized. Only the first letter is capitalized unless the acronym is the first word of a camelCasing style identifier.

Do not capital any letter of the first letter in the head of a camelCasing-style identifier, regardless of the length of the first letter.

Do not capital the first letter of each word in a closed compound.

Do not think that all programming languages are case sensitive. This is not the case. Names cannot be distinguished only by case.

　　

3.2 General naming conventions

Select an easy-to-read name for the identifier.

We need to pay more attention to readability than to simplicity.

Do not use underscores, hyphens, or any other character that is neither alphanumeric nor alphanumeric.

Do not use the Hungarian naming method.

Avoid using identifiers that conflict with keywords in a widely used programming language.

Do not use acronyms and acronyms as part of the identifier name. For example, you need to use GetWindow instead of GetWin.

Do not use unwidely accepted acronyms. Even the widely accepted first-character acronyms should be used only when necessary.

You must use a semantic name for the Type name instead of a language-specific keyword.

You need to use the common type name of CLR instead of the alias specific to the language-if there is no semantics for the identifier except for the type.

Use a common name, such as value or item, instead of repeating the type name-if there are no semantics for the identifier except the type, and the type of the parameter is irrelevant.

You must use a name similar to the old one when creating a new version of an existing API.

The suffix rather than the prefix should be used to indicate the new version of the existing API.

Consider using brand new but meaningful identifiers instead of simply adding suffixes or prefixes to existing identifiers.

Use a digital suffix to indicate a new version of an existing API-if the name of an existing API is a unique meaningful name (that is, it is an industrial standard), it is not appropriate to add a suffix (or rename it ).

Do not use the "Ex" (or similar) Suffix in the identifier to differentiate different versions of the same API.

The suffix "64" is used for new APIs that require operations on 64-bit integers (long) instead of 32-bit integers. This method is only required when a 32-bit API already exists. This method is not required for a new 64-bit API.

　　

 

 

[Source] http://www.cnblogs.com/liqingwen/p/7152673.html