C ++ software development specifications (II)

2 naming rules

The famous naming rule adopts the "Hungary" naming method. The main idea of this naming rule is to "add a prefix to the variable and function name to improve people's understanding of the program ". For example, all character variables are prefixed with CH, and if it is a pointer variable, the prefix P is appended. If a variable starts with PPCH, it indicates that it is a pointer to a character pointer.

The biggest disadvantage of the "Hungary" law is that it is cumbersome, for example

Int I, J, K;

Float x, y, z;

If the "Hungary" Naming rule is used, it should be written

Int II, IJ, ik; // prefix I indicates int type

Float FX, fy, Fz; // prefix F indicates Float Type

Such cumbersome programs will make the vast majority of programmers intolerable.

In general, there is no naming rule that can be endorsed by all programmers, and naming rules are not a "success or failure" thing for software products, in addition, the rules that should be followed by programs written on different platforms and in different environments are also different. Therefore, we just want to develop a naming rule that satisfies most project members, and implement it in the project.

2.1 common principles

The common rules discussed in this section are adopted by most programmers. We should follow these common rules to expand specific rules, such as section 2.2.

 

☆[ Rule 2.1-1] The identifier should be intuitive and readable. It is expected to be informative and does not need to be decoded ";

☆[ Rule 2.1-2] The length of the identifier shall comply with the "min-length & max-information" principle;

☆[ Rule 2.1-3] naming Rules should be consistent with the operating system or development tool style as much as possible;

☆[ Rule 2.1-4] do not show similar identifiers that are case sensitive only.

☆[ Rule 2.1-5] do not show local variables and global variables with identical identifiers in the program. Although the scopes of the two are different and there will be no syntax errors, they may be misunderstood;

☆[ Rule 2.1-6] The variable name should use "noun" or "Adjective + noun ";

☆[ Rule 2.1-7] The name of a global function should use "verb" or "Verb + noun" (verb phrase );

☆Rules 2.1-8: use the correct antonym group to name variables with mutex meanings or functions with opposite actions;

☆[ 2.1-1] avoid numbers in the name, such as value1 and value2, unless the numbers are required logically;

 

Note:

2.1.1 it is recommended that identifiers use English words or their combinations to facilitate memory and reading. Do not use Chinese pinyin for naming. Generally, English words in the program should not be too complex and should be accurate, for example, do not write currentvalue as nowvalue;

2.1.2 the length of the identifier should be the smallest length to achieve the most information. Generally, long names can better express the meaning, but not long variable names must be better than short variable names, the names of this extra single character are also useful. Common ones include I, J, K, M, N, x, y, and z. They can be used as local variables in the function;

2.1.3 different operating systems have different programming styles. For example, the identifiers of Windows applications usually adopt the "case-insensitive" hybrid sorting method, such as addchild, UNIX Application Identifiers generally use the "lowercase and underline" method, such as add_child. Do not mix these two styles;

2.2 Windows variable naming rules

☆[ Rule 2.2-1] The naming rule for variables requires the "Hungary rule", that is, the type of the variable used for the start letter, and the other part uses the English meaning of the variable or its abbreviation, do not use Chinese pinyin as much as possible, and the first letter of the word must be capitalized;

That is, variable name = variable type + variable meaning (or abbreviation)

For more information about variable types, see table 1-variable type table;

☆[ Rule 2.2-2] The class name and function name are combined with words starting with an upper-case letter. The type defined for the naming requirements of struct, union, and class variables is capitalized, the structure starts with S, the Consortium starts with U, and the class starts with C;

For example:

Struct SPoint

{

Int m_nX;

Int m_nY;

};

Union URecordLen

{

BYTE m_byRecordNum;

BYTE m_byRecordLen;

}

Class CNode

{

// Class member variables or member functions

};

☆[ Rule 2.2-3] The basic principle for naming pointer variables is:

The basic principle of a heavy pointer variable is:

Variable name = "p" + variable type prefix + name

The basic principles for multiple pointer variables are:

Double pointer:

Variable name = "pp" + variable type prefix + name

Triple pointer:

Variable name = "ppp" + variable type prefix + name

......

For example, a short * type variable should be represented as pnStart;

"> ☆[ Rule 2.2-4] A global variable starts with g _. For example, a global long variable is defined as g_lFileNum,

That is, the variable name = g _ + variable type + the meaning (or abbreviation) of the variable );

☆[ Rule 2.2-5] Static variables start with s _. For example, a static pointer variable is defined as s_plPrevInst,

That is, the variable name = s _ + variable type + the meaning (or abbreviation) of the variable );

☆[ Rule 2.2-6] class member variables start with m _. For example, a long member variable is defined as m_lCount,

That is, the variable name = m _ + variable type + the meaning (or abbreviation) of the variable );

☆[ Rule 2.2-7] const variables require that c _ be added before the naming rule of the variable (if it is used as the input parameter of the function, it can be left blank ),

That is, the variable name = c _ + variable naming rules, such:

Const char * c_szFileName;

☆[ Rule 2.2-8] for variables of the enumeration type (enum), the prefix of the enumerated variable or its abbreviation is required, and the variable name is isolated by underline. All enumeration types must be capitalized, for example:

Enum EMDAYS

{

EMDAYS_MONDAY;

EMDAYS_TUESDAY;

......

};

☆[ Rule 2.2-9] naming a constant (including an incorrect code) requires that the constant name be capitalized. The constant name represents its meaning in English, and words are separated by underscores. For example:

# Define CM_7816_ OK 0x9000;

☆[ Rule 2.2-10] to prevent conflicts between some identifiers in a software library and other software libraries, you can add prefixes that reflect the nature of software for various identifiers. For example, all library functions of 3D graphics standard OpenGL start with gl, and all constants (or macro definitions) start with GL.

3 program Style

Although the program style does not affect the functions of the program,

But it will affect the readability of the program, and the pursuit of clarity and beauty is an important component of the Program style.

3.1 blank lines

Empty rows separate program paragraphs. The program layout will be clearer if there are few blank lines. Empty rows do not waste memory. Although printing programs containing empty rows will consume more paper, it is worth it.

 

☆[ Rule 3.1-1] adds blank lines after each class declaration and after each function definition. See example 3.1 ();

☆[ Rule 3.1-2] In a function, empty rows are not added between closely related statements on the Limit operator, and empty rows should be used to separate them elsewhere.

3.2 code lines

☆[ Rule 3.2-1] a line of code only does one thing, for example, defining only one variable or writing only one statement. Such code is easy to read and easy to write comments;

☆[ Rule 3.2-2] if, for, while, do and other statements occupy one row, the execution statement cannot keep up with it, no matter how many statements are executed, add {}, this prevents writing errors;

☆[ Rule 3.2-3] if, for, while, do and other statements "{" must occupy a single line;

☆[ Recommended 3.2-1] All variables in the function are defined at the beginning of the function;

☆[ Recommended 3.2-2] initialize the variable whenever possible while defining the variable (proximity principle). If the reference of the variable is far away from its definition, variable Initialization is easy to forget. If uninitialized variables are referenced, program errors may occur. We recommend that you reduce the risk.