C ++ naming rules

C ++ naming convention

Common nomenclature:

Hungarian nomenclature: the basic principle is: variable name = attribute + type + object description, where the name of each object must have a clear meaning, you can take the full name of the object or part of the name. Naming should be based on principles that are easy to remember and understand. It's important to keep the name consistent.

Camel nomenclature: Camel-style nomenclature, because the name used in this nomenclature looks like the camel's hump. Camel nomenclature has two forms: a mix of uppercase and lowercase letters and underscores between words. For example, runFast and run_fast belong to Camel nomenclature.

Pascal Nomenclature: Similar to Camel nomenclature, but the initials of Pascal nomenclature are capital letters.

Naming rules:
1. In all nomenclature, standard English words or abbreviations should be used. Do not use Pinyin or Pinyin abbreviations, unless the name describes Chinese-specific content, such as half-width, full-width, initials, finals, etc.

2. All naming should follow the principle of knowing meaning, that is, the name should be clear and clear.

3. All names are not easy to be too long, and should be controlled within the specified maximum length.

4. All names should use full names as much as possible.

5. If you use abbreviations in your naming, you should use the abbreviations in the Common Abbreviation Table (see appendix); in principle, abbreviations other than the Common Abbreviation Table are not recommended. If you use them, you must comment and explain them.

Specific specifications:

1. Project name:

Unforced unification.

2. File name:

· Based on the project name, the first 3 letters should indicate which project is relevant.

· The following letters should be able to distinguish different functions.

·not case sensitive.

· The length is not limited to 8.3 format, it is recommended not to exceed 30 characters.

If the file is used to define and implement classes, it is recommended that the file name be consistent with the class name.

3. Function name:

· Refer to the Windows API naming convention.

· It is recommended to use a dynamic object structure. The function name should clearly reflect the function and purpose of the function.

The function name must not exceed 30 characters.

The first letter of the function name must be capitalized.

· Global functions must begin with a lowercase prefix "g".

4. Variable names:

In principle, naming of variable names follows Hungarian notation. That is: prefix + type + variable name

1) Format:

[m_ | s_ | g_] type [class name | struct name] variable name

2) Explanation:

· M_: member variables of the class

Ms_: static member variable of the class

· S_: static global variable

G_: ordinary global variables

· Type abbreviation (type)

· Char, TCHAR: ch

Char [], TCHAR []: sz

String: str

· Bool, BOOL: b

· Int, __int16, __ int32, __ int64: n

· Long: l

· Double: d

Float: f

· BYTE: by

· WORD: w

· DWORD: dw

· Unsigned: u

· Function: fn

· P: pointer

· Lp: long pointer

Variable names cannot exceed 20 characters.

5. Class name:

· Must start with an uppercase "C", followed by the letter to reflect the specific meaning, the principle of clearly expressing the purpose and function of the class

The interface must begin with an uppercase "I", which stands for Interface.

When the name consists of multiple words, the first letter of each word must be capitalized.

6. Structure name, macro name, enum name, joint name:

· All capitals.

Enumeration names are prefixed with a lowercase "enum".

example:

typedef enum _CFILE_OPEN_MODE

{

enumOPEN_READONLY = 0,

enumOPEN_READWRITE = 1,

enumCREATE_ALWAY = 3

} CFILE_OPEN_MODE;

// · The macro name is prefixed with a lowercase "def".

example:

#define defMAXNUMBER 100

Structure names are prefixed with a lowercase "tag" and must begin with an uppercase "C".

example:

typedef struct tagKPOINT

{

int x;

int y;

} KPOINT;

// · The joint name is prefixed with a lowercase "uni".

example:

typedef union _VARIANT {

char unichVal;

int uninVal;

long unilVal;

float uniftVal;

...

} VARIANT;

C / C ++ source code writing specification (trial)

1. There should be a uniform format at the beginning of .h / .cpp, including:

A. File Name (FileName);

B. Brief description of the function and purpose of the document (Comment);

C. Creater;

D. File creation time (Date).

example:

/ *!

* @ file

* @ brief

* @ author

* @ date

* /

2. Unless extremely simple, you should comment functions. The content includes: functions, entry / exit parameters, and comments or supplementary instructions if necessary.

3. The length of each line of code is recommended to be 80 columns, and the maximum length must not exceed 120 columns; line breaks are subject to alignment.

example:

HANDLE CSOpenFile (const char cszFileName [],
int nMode);

or:

BOOL CSReadFile (
HANDLE hFile,
void * pvBuffer,
int nReadSize,
int * pnReadSize
);

4. Loop, branch code, judgment conditions and execution code must not be on the same line.

Example: Correct:

if (n == -2)

n = 1;

else

n = 2;

Must not be written as:

if (n == -2) n = 1;

else n = 2;

5. Pointer definition, * can be either immediately after the type or before the variable name.

Example: can be written as: int * pnsize;

Can also be written as: int * pnsize;

But it must not be written as: int * pnsize;

6. When calling a non-member function within a member function of a class, you must add "::" before the non-member function name.

7. When the function entry parameters have default values, they should be commented.

example:

BOOL KSSaveToFile (const char cszFileName [], BOOL bCanReplace / * = TRUE * /);

or:

BOOL KSSaveToFile (const char cszFileName [], BOOL bCanReplace // = TRUE);

8. else if must be written on one line.

9. Provisions related to '{', '}':

9.1 '{', '}' shall be on its own line. There can be comments in this line.

Example: Correct:

for (i = 0; i

{// .....

printf ("Line% d:", i);

printf ("% s \ n", pFileLines);

}

Must not be written as:

for (i = 0; i

{printf ("Line% d:", i);
printf ("% s \ n", pFileLines);}

9.2 '{' must start on a new line, and the code after '{' must be indented by a tab. '{' And '}' must be on the same column.

Example: Correct:

if (i> 0)

{
m = 1;
n ++;

}

Must not be written as:

if (i> 0) {

m = 1;

n ++;

}

exception:

if (i == 0)

{ASSERT (FALSE); return;}

9.3 If there is only one line of code after a loop or branch, although '{', '}' can be omitted, this is not recommended. If it may cause ambiguity if omitted, ‘{’, ‘}’ must be added.

10. Space-related provisions.

10.1 There must be spaces on both sides of all binocular and trinocular operators. No spaces are required on both ends of the monocular operator. But before and after the operators such as '->', '::', '.', '[', ']', And after the operators '&' (address) and '*' (value) Space.

Example: Correct:

int n = 0, nTemp;

for (int i = nMinLine; i <= nMaxLine; i ++)

Must not be written as:

int n = 0, nTemp;

for (int i = nMinLine; i <= nMaxLine; i ++)

10.2 There should be a space after the keywords such as for, while and if, followed by '(', no space after it; there must be no space before the ending ')'.

Example: Correct:

if (-2 == n)

Must not be written as:

if (-2 == n)

or

if (-2 == n)

10.3 When calling functions and macros, there must be no spaces before or after '(', ')'.

Example: Correct:

printf ("% d \ n", nIndex);

Must not be written as:

printf ("% d \ n", nIndex);

printf ("% d \ n", nIndex);

10.4 When casting a type, there must be no spaces before or after ‘(’ ’)

Example: can be written as:

(KSFile *) pFile;

Can also be written as:

(KSFile *) pFile

Must not be written as:

(KSFile *) pFile

(KSFile *) pFile

11. Provisions related to indentation

11.1 Tabs are used for indentation. 1 Tab is 4 spaces

11.2 The code is indented by one tab if:

1. The relative function name of the function body and ‘{’, ‘}’.

example:

int Power (int x)

{

Return (x * x);

}

2. Code after if, else, for, while, do, etc.

3. If you cannot write within one line, the code after the line break should be lined in a reasonable place. Operators such as +-* / should be at the end of the previous line and not at the beginning of the next line.

11.3 Indentation is not necessary in the following cases: case after switch, default.

example:

switch (nID)

{

case ID_PLAY:

Uh ...

Break;

case ID_STOP:

Uh ...

Break;

default:

Uh ...

Break;

}

This article is transferred from the Silent Void Blog Garden blog, the original link: http://www.cnblogs.com/jingmoxukong/archive/2011/09/05/2167785.html, if you need to reprint, please contact the original author