Naming Conventions (2) general naming conventions

Naming Conventions (2) general naming conventions
Word Selection

For the name of the identifier in the framework, it is very important to achieve a clear effect. The identifier name should clearly express what each member is doing and what each type and parameter represents. The name should correspond to the application scenario, the logical or physical composition of the system, and well-known concepts, rather than the technology or architecture.

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

More emphasis on readability, rather than simplicity. The reason for naming the identifiers in the previous programming language is simple: At that time, the PC memory and disk space were very small and everyone had to compress as much as possible. For the current PC, you don't have to worry about this problem, so it is more important to be concise and readable.

Do not use underscores, hyphens, or any other character that is neither alphanumeric nor alphanumeric. For private fields, I prefer to add an underline prefix before the identifier.

Do not use the Hungarian naming method (basic principle: variable name = Attribute + Type + object description ). This naming method is common in C and C ++.

Avoid using identifiers that conflict with keywords in a widely used programming language. Although keywords can be used as identifiers by adding the "@" prefix in C #, it is much more difficult to use escape sequences when using methods. In the Razor Syntax of Asp. Net MVC development mode, the in-row expressions (variables and functions) both start. Therefore, it is not recommended to use this naming method with the "@" symbol.

Use the acronyms and acronyms

Do not use unwidely accepted acronyms and acronyms as part of an identifier name. So what is a widely accepted acronym? A test method is to directly input the abbreviation into the search engine. If the first few results returned are results related to the original meaning of the acronym, therefore, this acronym is well known.

Avoid using programming language-specific names

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

To use the common type of CLR, rather than the alias unique to the language (if there are no semantics for the identifier except for the type ).

Use a common name, such as value and item, instead of repeating the type name (if there is no other semantics for the identifier except the type, and the type of the parameter is irrelevant ). For example, void Write (int value );

Name a new version of an existing API

When a new feature needs to be added for an existing type, we cannot directly extend or reload the existing type members. Therefore, we can only add new members with different names.

You must use a name similar to the old API 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. It is commonly used to write C # extension methods.

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

Use a digital suffix to indicate a new version of an existing API (if the name of an existing API is the only meaningful name, that is, it is an industrial standard and is not suitable for adding a suffix or renaming ).

Use the suffix "64" when introducing a new API that uses 64-bit integers instead of 32-bit integers. This method is used when a 32-bit API already exists. This is not required for a new 64-bit API.