. NET design specification ———— naming conventions

NET design Specifications: conventions, idioms and patterns ——— naming conventions Foreword: Recently in the ". NET design Specifications: conventions, idioms and patterns of the book, mainly speaking. NET design specifications, before this piece is not particularly concerned about, recently want to put these systems to learn, the following is basically a reading notes it. Chapter III Naming specifications 3.1 casing conventions

Use the appropriate casing to make the identifiers of types, members, and parameters easier to read

3.1.1 Identifier capitalization principle

To distinguish multiple words in an identifier, capitalize the first letter of each word in the identifier, and have the following two appropriate ways to capitalize the letters in the identifier, as follows:

L Pascal Casing

L Camel Casing

The PascalCasing convention is used for all identifiers except the parameter name, which capitalizes the first letter of each word in the identifier. As shown below:

PropertyDescriptor

Html

An acronym of two letters Long is a special case where two letters are capitalized, as shown below:

IOStream

The Camel casing convention is used only for the name of the parameter, which capitalizes the first letter of all words except the first word in the identifier. As shown below:

PropertyDescriptor

Html

IoStream (identifiers start with a two-letter acronym and two letters are lowercase)

Identifier Base Case Specification:

To use Pascal casing for the namespaces, types, and names of the members that make up multiple words.

To use camel casing for the name of the parameter.

The casing rules for different types of identifiers are as follows:

3.1. Capitalization of 2 acronyms

It is important to avoid using acronyms in the names of identifiers, unless they are very common and can be understood immediately by those who use frames, such as HTML, XML, and so on.

The acronym must be at least two letters in terms of definition. Acronyms consisting of three or more letters follow the same specification as other words: only the first letter is capitalized, unless it is the first word in the camelcasing-style parameter name, in which case two letters are lowercase. As shown below:

public void Startio (Stream iostream,boolcloseiostream)

public void Porcesshtmltag (string htmltag)

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

System.IO

public void Startio (Streamiostream)

Capitalize the first letter of an acronym consisting of three or more than three letters. Unless it is the first word of a camelcasing style parameter name

System.Xml

Public Voidprocesshtmltag (String htmltag)

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

3.1.3 The case of compound words and common terms

When it comes to capitalization, most compound words are treated as a single word.

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

For example: endpoint, in order to unify the casing specification, we treat the closed form of compound words as a word.

The capitalization and spelling of commonly used compound words and common terms, as shown in:

The above example has two common other terms, OK and ID, which are themselves a category because they are commonly used abbreviations of slang nature

3.1.4 is case-sensitive

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

3.2 General Naming conventions

This chapter describes some common naming conventions, involving the choice of words, abbreviations, the use of acronyms, and how to avoid using names specific to programming languages.

3.2.1 The choice of words

The most important point for the name of the identifier in the frame is a glance. The meaning of the name is more important than the short length, and should correspond to the scene, the logical composition or physical composition of the system, and the concepts that are well known, and should not be aligned with the technical living architecture.

The main points are as follows:

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

It's more about readability than brevity.

Do not use underscores, hyphens, and any other characters that are not letters or numbers.

Do not use Hungarian nomenclature.

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

3.2.2 using Word abbreviations and acronyms

Do not use abbreviations and narrowing words as part of the identifier name.

Do not use an acronym that is not widely accepted (even if it is a widely accepted acronym, it should only be used when necessary)

3.2.3 avoid the use of language-specific names

To ensure that the framework can take full advantage of cross-language collaboration, it is important to avoid using language-specific type names in identifiers.

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 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, in addition to the type, the identifier has no other semantics, and the type of the parameter is not important.

3.2.4 naming a new version of an existing API

This section mainly describes how to choose a name for a new type and a new member to take over or replace an existing type or member.

Using a name similar to the old API when creating a new version of an existing API helps to highlight the relationship between APIs.

Example: Class appdommain{}

Class appdommainsetup{}

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 the API already has the only meaningful name, it is not appropriate to add a suffix.

Example: Publicclass x509certificate{}

public class x509certificate2{}

Do not use the "Ex" suffix in identifiers to differentiate between different versions of the same API.

Example: Publicclass car{}

public class carex{}//Error example

3.3 Naming of assemblies and DLLs

An assembly is a deployment unit and also represents the identity of a managed code program. In general, an assembly corresponds only to one DLL. This section focuses on DLL naming conventions, which are similar to the naming conventions for assemblies.

Remember that namespaces are a different concept from DLLs and assemblies. Namespaces are a logical set of entities for developers, while DLLs and assemblies are a unit at the time of packaging and deployment.

To choose a suggestive name for the assembly and DLL (for example: System.Data), it is easy to know its approximate functionality. The names of assemblies and DLLs do not have to correspond to namespaces, but it is also reasonable to follow the name of the namespace when the assembly is named.

Consider naming the DLL according to the following pattern:

<company>.<component>.dll

Where <Component> contains one or more words separated by dots, such as:

Microsoft.VisualBasic.dll

Microsoft.VisualBasic.Vsa.dll

3.4 Naming of the name space

The goal of the namespace is to be clear and user-friendly to the framework. The general namespace naming rules are as follows:

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

Examples are as follows:

Microsoft.visualstudio

Microsoft.VisualStudio.Design

Litware.security

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

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

L do not determine the hierarchy of namespaces based on the organization structure of the company, because the name of the company's internal organization generally does not last for too long.

L to use PascalCasing case style, Use the dot number to separate parts of the namespace (for example: Microsoft.office.PowerPoint). If the logo uses a non-traditional case style, then even if the style is contrary to the normal case style, it should follow the trademark's case style.

L Consider using negative numbers in namespaces when appropriate.

For example: Use System.Collections instead of system.collection. Except for trademarks and acronyms.

L do not use the same name to name the namespace and the type that is in the namespace.

For example, do not name the namespace debug, and then provide a class named Debug in the namespace.

namespace conflicts with type names

Namespaces are used to organize types into a logical, easy-to-navigate hierarchical structure. They are indispensable for resolving the two semantics of type names that can be caused when multiple namespaces are imported.

Do not introduce a type name that is too generalized (for example: Element,node,log,message)

Such names can easily cause type collisions, and namespaces may be categorized into the following categories:

L Application Model namespaces (Application Model namespace)

L Infrastructure namespace (infrastructure namespace)

L Core namespaces (cores namespace)

L Technical namespace groups (technology namespace Group)

1. Application Model namespaces

Do not give the same name to a type in the namespace of the same application model.

2. Infrastructure namespaces

This category contains namespaces that are rarely imported when developing commonly used applications.

3. Core namespaces

The core namespace contains all of the system namespaces, except for the application model namespace and the underlying settings namespaces. (core namespaces include System, System.IO, System.Xml, System.Net, etc.)

Do not give the name of a type that conflicts with any type in the core namespace. (For example: do not use stream as a type name, it will conflict with System.IO.Stream)

4. Technical name Space Group

This category includes all those with the same two prefixes (<company>.<technology>* Start namespaces (for example: Microsoft.Build.Utilities and Microsoft.Build.Tasks belong to the same technology type but do not conflict with each other)

Do not give names that conflict with other types that are located in the same technology group.

Do not introduce a type name conflict between the technical namespace and the type of the Application model namespace (for example: You should not add a binding type to the Microsoft.VisualBasic namespace because the System.Windows.Forms namespace already contains the type name)

3.5 Naming of classes, structs, and interfaces

In general, type names should be noun phrases, because they represent entities in the system, and if a noun phrase cannot be found for a type, then the overall design of that type might be reconsidered.

The most recognizable names should be used for the most commonly used types, and the most commonly used type names should reflect the usage scenario rather than the inheritance hierarchy. Most users use only the leaf nodes of the inheritance hierarchy, not the class hierarchy.

The following naming conventions apply to generic type naming.

To use nouns or noun phrases to name a type, in rare cases you can also use an adjective phrase to give the type a name. (named with the PascalCasing case style, which separates the type name from the method area, which is named after the verb phrase.) )

Do not prefix the class name. (The only prefix is for the interface "I")

Consider having the name of the derived class end with the name of the base class. (ex: Publicclass filestream:stream{...})

To have the name of the interface begin with the letter I, it shows that the type is an interface. (Example: IComponent)

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.

For example: public interface icomponent{...}

public class component:icomponent{...}

3.5.1 naming of generic type parameters

Generics are. NET Framework 2.0 is a major feature that introduces a new identifier called a type parameter (parameter). The following specification describes the naming conventions related to type parameters.

To name a generic type parameter with a descriptive name, unless a single letter is sufficient, and the descriptive name does not add value.

For example: public interface tsessionchannel<tsession>{...}

public class list<t>{...}

Consider using T to name the parameter type--if the type has only one type parameter, and the type parameter has only one letter.

For example: public int icomparer<t>{...}

Public delegate boolpredicate<t> (T item);

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

For example: public interface isessionchannel<tsession> Wheretsession:isession

{

TSession Session{get;}

}

Consider showing the restriction on the type parameter name that is applied to the type argument.

3.5.2 Naming of common types

If you want to start from. NET Framework to derive a new type, or to implement. NET Framework, follow one of the naming conventions in the following table. As shown below:

3.5. Naming of 3 enumerated types

In general, the naming of enumerated types should follow the standard naming conventions (pascalcasing case style). However, there are specific specifications for enumeration types.

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

To use a plural noun to name an enumeration type that represents a bit field, the enumeration type is also known as a tag enumeration (flag enum)

For example: [Flags]

public enum consolemodifiers{

Alt

Control,

Shift

}

Do not add an "enum" suffix to the name of the enumeration type.

For example: Public enum colorenum{...} That's not good.

Do not prefix the names of enumerated type values.

For example: Public enum imagemode{

Imagemodebitmap=0,

Imagemodegrayscale=1,

imagemodergb=2

}

The following naming is better:

public enum imagemode{

Bitmap=0,

Grayscale=1,

rgb=2

}

3.6 Naming of type members

A type consists of members such as methods, properties, events, constructors, and fields.

Naming the 3.6.1 method

Because the method is used to perform the operation, the framework's design specification requires that the method name be a verb or a verb phrase. It is also used to separate methods from attribute and type names, and attribute and type names are nouns or adjective phrases.

Use a verb or verb phrase to name the method.

Name of the 3.6.2 property

Unlike other members, attributes should be named by noun phrases or adjective phrases. Always use the PascalCasing case style when naming.

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.

To name a Boolean attribute, use a positive text message (CanSeek instead of Cantseek). If it helps, you can also selectively add "is" to the Boolean attribute, "can", and "has" prefixes.

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

For example: Public enum color{...}

public class control{

Public Color color{get{...} set{...}

}

Naming the 3.6.3 event

Events always represent actions that are either occurring or have occurred. Therefore, as with the method, the verb should be named, in addition, the tense of the verb to indicate the time when the event occurred.

Use a verb or verb phrase to name the event. (ex: Clicked,droppeddown, etc.)

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

For example: The Close event before the window closes is named closing, and the event after the shutdown is named closed

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

To add the "EventHandler" suffix to the name of the event handler. (For example: public delegate void Clickedeventhandler (object sender,clickedeventargse);

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

The parameter sender represents the object that triggered the event.

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

3.6. Naming of 4 fields

The naming conventions for fields apply to static common fields and static protected fields.

To use the PascalCasing case style when naming fields.

Use a noun or noun phrase to name the field.

Do not prefix field names. (Example: Do not use "g_" or "s_" to distinguish between static and non-static fields)

3.7 Naming of parameters

To use the camelcasing casing style when naming parameters.

To use a descriptive parameter name.

The parameter name should be descriptive enough that in most cases the user can determine its meaning based on the parameter name and type.

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

3.8 Naming of resources

A localized resource is like a property and can be referenced by a specific object. The naming convention for resources is therefore similar to the naming conventions for properties.

To use the pascalcasing capitalization style when naming resource keywords.

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

Do not use keywords that are specific to the various CLR programming languages.

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

Use a dot to clearly divide the identifiers into layers.

For example: Design menu system resources, named as follows:

Menus.FileMenu.Close.Text

Menus.FileMenu.Close.Color

To name the message resource for the exception, follow the following naming convention:

The resource identifier should be the type name of the exception plus a short exception identifier, separated by a dot:

Argumentexception.illegalcharacters

Argumentexception.invalidname

. NET design specification ———— naming conventions