Variable naming method in the program

When writing programs, we often use variables. to use them, we need to name the variables. In fact, we write programs to make money (at least I think so, because my food and clothing problems are hard to solve), this requires that the program we write can not only be understood by ourselves, but also by others. This requires us to have a specification for variable names.

Hungarian (Hungarian name) is a popular specification. Variables named in this method display their data types.

There are two kinds of Hungarian naming methods:

The system's Hungary naming method (prefix represents the actual data type of the variable) and the Hungary application naming method (does not represent the actual data type, but gives the variablePurpose).

In this naming method, a variable name starts with one or more lower-case letters, which help to remember the type and usefulness of the variable, followed by any name selected by the programmer. the first letter of the second half can be capitalized to distinguish the previous type indicator, that is, the hump type case:

When a variable or function name is connected by two or more words and forms a unique identifier, no space is required between words (such as hello
World). The connection line (hello-world) and the underscore (hello_world) are connected. There are two formats: the small camper method and the big camper method.

The first word starts with a lowercase letter, and the second word starts with an uppercase letter, such as helloworld.

Big camper naming: the first letter of each word starts with an uppercase letter. For example, helloworld .(Pascal naming).

However, what I want to talk about here is that although the Hungarian naming law is very popular, we should not use it well. Everything follows Microsoft's best requirements,

General naming conventions

 

The general naming convention discusses how to select the most appropriate name for the library element. These rules apply to all identifiers. The following sections discuss the naming of specific elements (such as namespaces or attributes.

Select name

Select a readable identifier name. For example, the English attribute name horizontalalignment Ratio
Alignmenthorizontal is more readable.

 

Readability is more important than simplicity. Attribute name canscrollhorizontally Ratio
Scrollablex (X axis, but ambiguous) is better.

Case sensitivity

 

Many naming conventions are related to the case sensitivity of identifiers. It is worth noting that the Common Language Runtime Library (CLR) supports case-sensitive and case-insensitive languages. The case sensitivity conventions described in this topic help developers understand and use libraries.

Case Sensitive Style

The following terms describe different cases of identifiers.

Pascal case

The first letter of the identifier and the first letter of each word connected to the end are capitalized. You can use Pascal case for a three-character or more-character identifier. For example:

Backcolor

Case sensitivity

The first letter of the identifier is lowercase, and the first letter of each connected word is uppercase. For example:

Backcolor

Uppercase

All letters in the identifier are in uppercase. For example:

Io

Case sensitivity rules for Identifiers

If an identifier is composed of multiple words, do not use separators between words, such as underscores (_) or hyphens. The case should be used to indicate the beginning of each word.

The following are general rules for identifiers.

For all public members, types, and namespace names composed of multiple words, use Pascal case.

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

Use case-insensitive mixing for parameter names.

The following table summarizes the upper and lower case rules of identifiers and provides examples of different types of identifiers.

 

Identifier	Case sensitivity	Example
Class	Pascal	Appdomain
Enumeration type	Pascal	Errorlevel
Enumerated Value	Pascal	FatalError
Event	Pascal	Valuechanged
Exception	Pascal	Webexception
Read-only static Fields	Pascal	Redvalue
Interface	Pascal	Idisposable
Method	Pascal	Tostring
Namespace	Pascal	System. Drawing
Parameters	Camel	Typename
Attribute	Pascal	Backcolor

Uppercase/lowercase rules for acronyms

An acronym is a word that consists of the first letters of each word in a term or phrase. For example, HTML is the abbreviation of hypertext markup language. Acronyms should be used in identifiers only when the public is widely aware and understood. The acronym is different from the acronym because it is the abbreviation of a word. For example, ID is the abbreviation of identifier. Generally, the Library name should not use acronyms.

Note:
The two acronyms that can be used in the identifier are ID and OK. In PASCAL case-sensitive identifiers, the uppercase and lowercase formats of these two acronyms should be ID and OK, respectively. If the two acronyms are used as the first word in a case-insensitive identifier, they should be in the case of ID and OK, respectively.

The case sensitivity of the first letter is determined by the length of the first letter. All acronyms must contain at least two characters. To facilitate the implementation of these principles, if a letter's acronym exactly contains two characters, it will be considered as a short-type acronym. The acronyms that contain three or more characters are long-form acronyms.

The following criteria specify the correct case-sensitive rules for short and long acronyms. The uppercase/lowercase rules of identifiers take precedence over those of acronyms.

The two characters must be capitalized, except when the first word of an acronym is used as an identifier in a case-insensitive format.

For example, the attribute "dbrate" is an identifier in Pascal case format. It uses the short-type acronyms (db) as the first word. For example, the parameter named iochannel is an identifier in case-insensitive format. It uses the short-type acronyms (IO) as the first word.

Only the first character is capitalized, except when the first character is used as the first word of the case-insensitive identifier.

For example, the class named xmlwriter is an identifier in Pascal case format. It uses the long-form acronyms as the first word. For example, the parameter "htmlreader" is an identifier in case-insensitive format. It uses the long-form acronyms as the first word.

If an acronym starts with an identifier in a case-insensitive format, no character is capitalized regardless of the length of the acronym.

For example, a parameter named xmlstream is an identifier in case-insensitive format. It uses the long-form acronyms (XML) as the first word. For example, the parameter "dbservername" is an identifier in case-insensitive format. It uses the abbreviation dB as the first word.

The case-sensitivity rules of Compound Words and common terms do not uppercase each word in the so-called compact format compound word. This composite refers to the composite word used to write a word, such as "endpoint ".

For example, hashtable is a composite word in a compact format. It should be considered as a word and case-sensitive accordingly. If the Pascal case format is used, the compound word is hashtable. If the case-sensitive format is used, the compound word is hashtable. To determine whether a word is a composite word in a compact format, refer to the latest dictionary.

The following table lists some common terms that are not composite words in a compact format. The term is first displayed in Pascal's case-sensitive format, followed by a mix of uppercase and lowercase characters.

• Bitflag)

• Filename (filename)

• Logoff (logoff)

• Logon (logon)

• Signin (signin)

• Signout (signout)

• Username (username)

• Whitespace (whitespace)

Case Sensitive

The case sensitivity criterion is used only to make the identifier easier to read and recognize. Case sensitivity rules cannot be used to prevent name conflicts between database elements.

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

Do not use underscores, hyphens, or any other non-alphanumeric characters.

 

Do not use Hungarian notation.

Hungary notation uses a prefix to encode certain metadata of a parameter in an identifier, such as the Data Type of the identifier.

 

Avoid using identifiers that conflict with keywords in common programming languages.

Although CLS-compliant languages must provide methods to use keywords as common words, best practices do not require developers to understand how to implement them. For most programming languages, the language reference documentation provides a list of keywords used by the language. The following table provides links to reference documents for some common programming languages.

 

Language	Link
C #	C # reference
C ++	C ++ Language Reference
Visual Basic	Visual Basic Reference

Abbreviations and acronyms

Generally, abbreviations or acronyms are not allowed. This type of name is less readable. Similarly, it is difficult to determine whether an acronym is widely recognized.

For the case-sensitive rules of abbreviations, see the case-sensitive rules for acronyms.

Do not use abbreviations or abbreviations as part of the identifier name.

For example, use onbuttonclick instead of onbtnclick.

 

Do not use any unaccepted acronyms unless necessary.

Language-specific name

For a type name, use a semantic name instead of a language-specific keyword. For example, the name getlength Ratio
Getint is better.

 

In rare cases where the semantic meaning of an identifier is limited to its type, the general Common Language Runtime (CLR) should be used)
Type name, rather than language-specific names.

For example, the method for converting data to int16 should be named toint16 instead of toshort, becauseShortYesInt16Language-specific type name.

The following table shows the type names specific to the common programming language and CLR.

 

C # type name	Visual Basic type name	JScript type name	Visual c ++ type name	Ilasm.exe Representation	CLR type name
Sbyte	Sbyte	Sbyte	Char	Int8	Sbyte
Byte	Byte	Byte	Unsigned char	Unsigned int8	Byte
Short	Short	Short	Short	Int16	Int16
Ushort	Uint16	Ushort	Unsigned short	Unsigned int16	Uint16
Int	Integer	Int	Int	Int32	Int32
Uint	Uint32	Uint	Unsigned int	Unsigned int32	Uint32
Long	Long	Long	_ Int64	Int64	Int64
Ulong	Uint64	Ulong	Unsigned _ int64	Unsigned int64	Uint64
Float	Single	Float	Float	Float32	Single
Double	Double	Double	Double	Float64	Double
Bool	Boolean	Boolean	Bool	Bool	Boolean
Char	Char	Char	Wchar_t	Char	Char
String	String	String	String	String	String
Object	Object	Object	Object	Object	Object

 

In rare cases where the identifier has no semantic meaning and the parameter type is not important, use a common name (such as a value or item) instead of repeating the type name.