Microsoft recommended. NET naming conventions

Many naming conventions are related to the case of identifiers. It is important to note that the common language runtime (CLR) supports case-sensitive and case-insensitive languages. The casing conventions that are described in this topic help developers understand and use libraries.

Case style

The following terms describe the different casing forms of identifiers.

Pascal case

Capitalize the first letter of the identifier and the first letter of each word that is connected to it later. You can use Pascal casing for identifiers of three or more characters. For example:

BackColor

Mixed case

The first letter of the identifier is lowercase, and the first letter of each subsequent concatenated word is capitalized. For example:

BackColor

Capital

All letters in the identifier are capitalized. For example:

Io

Casing rules for identifiers

If the identifier consists of more than one word, do not use a delimiter between the words, such as an underscore ("_") or a hyphen ("-"). Instead, use case to indicate the beginning of each word.

The following guidelines are general rules for identifiers.

For all public members, types, and namespace names that consist of multiple words, use Pascal casing.

Note that this rule does not apply to instance fields. Public instance fields should not be used because of the reasons explained in detail in the member design guidelines.

Use case blending for parameter names.

The following table summarizes the casing rules for identifiers and provides examples of different types of identifiers.

identifiers	Case Method	Example
Class	Pascal	AppDomain
Enum type	Pascal	ErrorLevel
Enumeration values	Pascal	FatalError
Event	Pascal	ValueChanged
Exception class	Pascal	WebException
Read-only static fields	Pascal	Redvalue
Interface	Pascal	IDisposable
Method	Pascal	Tostring
Name space	Pascal	System.Drawing
Parameters	Camel	TypeName
Property	Pascal	BackColor

Case rules for acronyms

Acronyms are words that consist of the first letter of each word in a term or phrase. For example, HTML is an acronym for Hypertext Markup Language. Acronyms should be used in identifiers only if they are widely recognized and understood by the public. Acronyms are different from abbreviations because abbreviations are abbreviations for a word. For example, theID is an abbreviation for identifier . Typically, the library name should not use abbreviations.

The two abbreviations that can be used in identifiers are ID and OK. In the case of Pascal-cased identifiers, the two abbreviations should be case- Id and Ok, respectively. If the two abbreviations are used as the first word in an identifier in mixed-case format, they should be in the case of ID and OK, respectively.

The case of an acronym depends on the length of the acronym. All acronyms should contain a minimum of two characters. To facilitate the implementation of these guidelines, if an acronym contains exactly two characters, it is treated as a short acronym. An acronym that contains three or more than three characters is a long-type acronym.

The following guidelines specify the correct casing rules for short and long acronyms. Identifier casing rules take precedence over acronym casing rules.

The two characters of the two-character acronym are capitalized, except when the initials are the first word of an identifier in mixed-case format.

For example, a property named dbrate is a Pascal-cased identifier that uses the short acronym (DB) as the first word. As another example, a parameter named Iochannel is an identifier in a mixed-case format that uses the short acronym (IO) as the first word.

Acronyms that contain three or more characters are capitalized only in the first character, except when the acronym is the first word in a mixed-format identifier.

For example, a class named XmlWriter is a Pascal-cased identifier that uses a long acronym as the first word. As another example, a parameter named HtmlReader is an identifier in a mixed-case format that uses the long acronym as the first word.

If any acronym is at the beginning of an identifier in a mixed-case format, no matter what the length of the acronym is, no characters are written.

For example, a parameter named Xmlstream is an identifier in a mixed-case format that uses the long acronym (XML) as the first word. As another example, a parameter named DbServerName is an identifier in a mixed-case format that uses the short acronym (DB) as the first word.

Casing rules for compound words and common terms do not capitalize each word in the so-called compact form compound. This compound refers to a compound word that is written in one of the words, such as "endpoint".

For example,Hashtable is a compound word in a compact format, which should be treated as a phrase and appropriately case-sensitive. If in Pascal case format, the compound word is Hashtable, and if mixed in case, the compound word is Hashtable. To determine whether a word is a compact compound, consult the latest dictionary.

Universal Naming conventions

The universal Naming convention discusses how to select the most appropriate name for a library element. These guidelines apply to all identifiers. The following sections discuss the naming of specific elements, such as namespaces or attributes.

Select Name Select the readable identifier name. For example, the English attribute name HorizontalAlignment is more readable than alignmenthorizontal. Readability is more important than brevity. The property name canscrollhorizontally is better than Scrollablex (referring to the X-axis, but the meaning is ambiguous). Do not use underscores, hyphens, or any other non-alphanumeric characters. Do not use Hungarian notation.

Hungarian notation is a prefix used in identifiers to encode some metadata for a parameter, such as the data type of an identifier.

Names of assemblies and DLLs

In most cases, an assembly contains all or part of a reusable library, and it is contained in a single dynamic-link library (DLL). An assembly can be split into multiple DLLs, but this is very rare and is not described in this guideline.

Assemblies and DLLs are the physical organization of a library, and namespaces are logical organizations, and their composition should be independent of the organization of the Assembly. Namespaces can and often span multiple assemblies.

Be sure to select the name of the assembly DLL that indicates a large feature block (such as System.Data). The names of assemblies and DLLs do not have to correspond to namespace names, but it is reasonable to follow the namespace name when naming the assembly. Consider naming the DLLs in the following mode:

<company>.<component>.dll

Where <Component> contains one or more clauses separated by dots.

For example,Contoso.WebControls.dll.

Name of the namespace

The name you choose for the namespace should indicate the functionality provided by the type in the namespace. For example, the System.Net.Sockets namespace contains types that allow developers to communicate over the network using sockets.

The general format of the namespace name is as follows:

<company>. (<Product>|<Technology>) [. <feature>] [. <subnamespace>]

For example,Microsoft.WindowsMobile.DirectX.

Use the company name as a prefix to the namespace to prevent the namespaces that are developed by different companies from having the same name and prefix. The second level of the namespace name uses a stable, version-independent product name. Do not determine the name of the namespace hierarchy based on the organization hierarchy, because the company's department name may change over time.

The namespace name is an identifier that is used for a long time and does not change. The continuous development and change of the Organization should not make the namespace name obsolete.

Use Pascal case format and separate the parts of the namespace (such as Microsoft.Office.PowerPoint) with a period. If your brand takes a non-traditional case, you should follow the case defined by your brand, even if it deviates from the usual namespace capitalization. Consider using the plural namespace name when appropriate. For example, use System.Collections instead of using System.Collection. However, the brand name and acronym belong to the exception of this rule. For example, use System.IO instead of using System.ios. Do not use the same name for the namespace and the type within it. For example, do not provide a class named "Debug" in this namespace while "Debug" is used as the namespace name. Some compilers require that this type be fully qualified. Name conflicts for namespaces and types

If the name of the selected namespace or type conflicts with an existing name, the user of the library will have to qualify the reference to the affected item. In most development scenarios, this problem should not occur.

Some of the guidelines provided in this section apply to the following namespace categories:

• Application Model namespaces

• Infrastructure namespaces

• Core namespaces

• Technology Namespace Group

Namespaces in the application model provide a set of features that are specific to a class in your application. For example, the types in the System.Windows.Forms namespace provide the functionality required to write a Windows forms client application. The types in the System.Web namespace support writing Web-based server applications. Typically, namespaces in different application models are not used in the same application, so this reduces the likelihood of name collisions affecting developers who use your library.

Infrastructure applications provide specialized support and are rarely referenced in program code. For example, the Program development tool uses the *. The type in the Designer namespace. *. The Permissions namespace is another example of an infrastructure namespace. A name conflict with a type in the infrastructure namespace cannot affect the developer who uses your library.

The core namespace is System. * Namespaces (excluding application namespaces and infrastructure namespaces). Both System and System.Text are examples of core namespaces. When possible, avoid name collisions with types in the core namespace.

Namespaces that belong to a particular technology will have the same first and second level identifiers (company.technology.*). You should avoid name collisions in the technology namespace.

Namespace general guidelines do not introduce a broad type name, such as Element, Node, Log, and Message. In general, this can lead to a type name conflict. A broad type name should be qualified (for example, FormElement, XmlNode EventLog, SoapMessage). Application namespace guidelines do not specify the same name for multiple types in a namespace within a single application model.

For example, if you are writing a special control library to be used by Windows forms application developers, you should not introduce a type named checkbox , because the application model already has a type (checkbox) with the same name.

Core namespace guidelines do not specify a type name that will conflict with any type in the core namespace.

For example, do not use directory as a type name because it conflicts with the directory type.

Technology namespace guidelines do not assign type names that conflict with other types within a single technology namespace. Do not introduce a type name that causes a type in the technology namespace to conflict with a type in the Application model namespace (unless the technology is not used for the application model).

Microsoft recommended. NET naming conventions