Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "C language and C++ naming conventions and common naming methods". Many people will encounter this dilemma in the operation of actual cases. then let the editor lead you to learn how to deal with these situations! I hope you can read it carefully and be able to achieve something!

1. Naming convention

The first article in this series, naming style is about artistic aesthetics, there is no absolute standard of beauty and ugliness, this article inevitably has a subjective choice tendency, but will try to maintain an objective attitude to sum up several mainstream naming styles for reference only. Specifications are developed to facilitate team communication and code maintenance, although not to the taste of every artist. For independent developers, taking the time to design your own coding style can also help improve your ability, or at least feel beautiful when you see your own code. This article refers to, of course, Wikipedia, which will not be repeated in the future.

1.1. Common nomenclature

Snake nomenclature [snake_case]:

Like_this is commonly found in Linux kernel, C++ standard library, Boost, Ruby,Rust and other languages.

Hump nomenclature [camelCase]:

LikeThis, in order to distinguish from Pascal nomenclature, this paper specifically refers to the small hump nomenclature, which is common in Qt and Java.

Pascal nomenclature [PascalCase]:

LikeThis, also known as Big Hump nomenclature, is commonly found in Windows API functions and C #.

Hungarian nomenclature [Hungarian notation]:

DwWidth, the system Hungarian nomenclature is the most frequently hacked, and it is mainly believed that the compiler is more reliable than people to find type errors in languages with type checking; in the case of IDE, it is not difficult to find the type of a variable; usually when we see a strange variable, it seems useless to know its type if we don't know what it does. And when refactoring, if you want to change the type of a variable, even though its function has not changed, you still have to change the variable name. Therefore, it is not recommended to use the system Hungarian nomenclature unless it is a Windows system development.

RwPosition, Hungary uses nomenclature not to indicate the type of variable, but to use a prefix to indicate the purpose of the variable, or what it represents. This variable naming method is very helpful in helping programmers understand the purpose of variables. However, it is recommended that abbreviations are not used in prefixes unless the abbreviations used are generally accepted.

C is a simple language, and the name you use should be the same. Unlike Modula-2 and Pascal programmers, C programmers do not use "smart" names such as "ThisVariableIsATemporaryCounter". C programmers should call it "tmp", which is easier to write and not more difficult to understand.

However, it can be tricky when faced with complex situations, and it is necessary to give a descriptive name to the global variable. Calling a global function "foo" is a short-sighted behavior. The same goes for global functions. If you have a function that counts the number of current users, you should name it "count_active_user ()" or something like that, not "cntusr ()".

1. Three popular naming rules

At present, there are four naming rules in the industry: hump naming, Hungarian naming, Pascal naming and underlining naming, of which the first three are more popular naming methods.

(1) Hump command method. As its name suggests, it refers to the mixed use of uppercase and lowercase letters to form the names of variables and functions. For example, here is the same function named with camel naming and underscore, respectively:

PrintEmployeePaychecks ()

Print_employee_paychecks ()

The first function name uses the hump naming method, and each logical breakpoint in the function name is marked with an uppercase letter. The second function name uses the underscore method, and each logical breakpoint in the function name is marked with an underscore.

Hump naming has become more and more popular in recent years, and it is often used appropriately in many new function libraries and environments such as Microsoft Windows. On the other hand, underlining has become popular since the advent of C, and it is very common in many older programs and environments such as UNIX.

(2) Hungarian nomenclature. It is widely used in environments like Microsoft Windows. Variables (including macros) used in Windows programming are named by Hungarian nomenclature, which was proposed by a capable Microsoft programmer, Charles Simone (Charles Simonyi).

The Hungarian nomenclature identifies the scope and type of the variable by prefixing it with the symbol identification of the corresponding lowercase letters in front of the variable name. These symbols can be used at the same time, in the order of m _ (member variables), pointers, simple data types, and so on. The advantage of this is that it can increase the readability of the program and facilitate the understanding and maintenance of the program.

For example: m_lpszStr represents a long pointer member variable that points to a string that ends with a 0 character.

The key to Hungarian naming is that the name of the identifier begins with one or more lowercase letters as a prefix; the prefix is followed by an uppercase word or combinations of words that indicate the purpose of the variable.

(3) pascal nomenclature. Similar to hump naming, the difference is that hump naming is lowercase, while Pascal naming is capitalized, such as:

DisplayInfo ()

String UserName

Both use Pascal nomenclature.

(4) A summary of three naming rules: MyData is an example of Pascal naming; myData is a hump nomenclature in which the first letter of the first word is lowercase, followed by an uppercase word that looks like a camel; and iMyData is a Hungarian nomenclature whose lowercase I indicates its type, followed by the same name as Pascal, indicating the purpose of the variable.

2. The basic principles of naming

(1) the naming of identifiers should be clear, clear and have a clear meaning, and use complete words or abbreviations that everyone can understand at the same time to avoid misunderstanding-use English words or all Chinese spelling as far as possible. If there is a mixed definition of English words and Chinese, use the hyphen "_" to separate English and Chinese. Shorter words can be abbreviated by removing vowels; longer words can be abbreviated by the first few letters of the word; and some words have accepted abbreviations. For example: temp- > tmp, flag- > flg, statistic- > stat, increment- > inc, message- > msg and other abbreviations can be basically recognized by everyone.

(2) if special conventions or abbreviations are used in naming, there should be comments. The necessary comments should be made at the beginning of the source file about the abbreviations or conventions used in the file, especially the special abbreviations.

(3) one's own unique naming style should be consistent from beginning to end and should not be changed back and forth. Personal naming style can only be used if it conforms to the naming rules of the project group or product group. (that is, where there is no provision in the naming rules, there can be a personal naming style.)

(4) for variable naming, it is forbidden to take single characters (such as I, j, k. It is suggested that it should not only have a specific meaning, but also indicate its variable type, data type, etc., but I, j, k are allowed to be local cyclic variables. Variables, especially local variables, are easily mistyped (such as I written as j) if they are represented by a single character, and cannot be checked at compile time, so it is possible to spend a lot of time checking errors for this small error.

(5) do not use numbers or strange characters to define identifiers unless necessary.

(6) the naming convention must be consistent with the system style used and unified in the same project.

(7) in the same software product, the naming of interface part identifiers (variables, structures, functions and constants) should be planned to prevent conflicts during compilation and linking. There should be stricter restrictions on the identifiers of the interface section to prevent conflicts. For example, you can specify the interface part of the variables and constants before the "module" identification, and so on.

(8) name variables with mutually exclusive meaning or functions of opposite actions with correct antonyms.

Here are some antonyms commonly used in software.

Add / remove begin / end create / destroy

Insert / delete first / last g et / release

Increment / decrement put / get

Add / delete lock / unlock open / close

Min / max old / new start / stop

Next / previous source / target show / hide

Send / receive source / destination

Cut / paste up / down

Example:

Int min_sum

Int max_sum

Int add_user (BYTE * user_name)

Int delete_user (BYTE * user_name)

(9) except for special applications such as compiling switches / headers, you should avoid using definitions such as the beginning and end of underscores such as _ EXAMPLE_TEST_.

3. Naming rules for variable names

(1) the naming rules of variables require the use of the "Hungarian rule".

That is, the first letter uses the type of variable, and the rest uses the English meaning of the variable, the English abbreviation, the Chinese full spelling or the Chinese full spelling abbreviation, requiring that the first letter of the word should be capitalized.

That is, variable name = variable type + English meaning of variable (or English abbreviation, Chinese full spelling, Chinese full spelling abbreviation)

For non-general variables, add comments when defining, and the variable definition should be placed at the beginning of the function as far as possible.

See the following table:

Bool starts bFlg with b

Int starts iCount with I

Short int starts nStepCount with n

Long int starts lSum with l

Char starts cCount with c

Unsigned char begins with by

Float starts fAvg with f

Double starts dDeta with d

Unsigned int (WORD) starts wCount with w

Unsigned long int (DWORD) begins dwBroad with dw

The string begins with s and sFileName

A string ending with 0 begins szFileName with sz

(2) the basic principles of pointer variable naming are:

The basic principle for multiple pointer variables is "p" + variable type prefix + naming, for example, a float* type should be represented as pfStat. The basic rule for double pointer variables is "pp" + variable type prefix + naming. The basic rule for triple pointer variables is "ppp" + variable type prefix + naming.

(3) Global variables start with g.For example, a global long variable is defined as g_lFailCount. That is, variable name = gathers + variable type + variable meaning (or abbreviation). This rule also avoids problems caused by local and global variables with the same name.

(4) static variables start with s _, for example, a static pointer variable is defined as s_plPerv_Inst. That is, variable name = variable + variable type + English meaning of variable (or abbreviation)

(5) for variables in enumerated types (enum), enumerated variables or their abbreviations are required to be prefixed. And require uppercase. Such as:

Enum cmEMDAYS

{

EMDAYS_MONDAY

EMDAYS_TUESDAY

……

}

(6) the naming of struct and union variables requires that the defined type be capitalized. It should be prefixed, and the naming rules of its internal variables are the same as those of variables.

The structure usually starts with S, such as:

Struct ScmNPoint

{

X position of int nX;// point

Y position of int nY; / / point

}

Consortia usually start with U, such as:

Union UcmLPoint

{

LONG lX

LONG lY

}

(7) to name constants (including incorrect codes), require constant names to be capitalized, and constant names to express their meaning in English. When it needs to be represented by multiple words, the word must be connected by a hyphen "_".

For example: # define CM_FILE_NOT_FOUND CMMAKEHR (0X20B), where CM represents a category.

(8) the variable of const is required to add c _ before the naming convention of the variable. That is, censor + variable naming rules; example: const char* c_szFileName

4. the naming convention of the function

(1) the naming of the function should express the function of the function in English (or English abbreviation, Chinese full spelling, Chinese full spelling) as far as possible-the function name should accurately describe the function of the function. Follow the naming rule of the verb-object structure, the verb comes first in the function name, and the prefix of the function is added before the naming, and the length of the function name shall not be less than 8 letters. The first letter of the function name is capitalized, if the first letter of each word containing two words is capitalized. If it is an OOP method, there can be only verbs (nouns are objects themselves). Example:

LONG GetDeviceCount (…)

Void print_record (unsigned int rec_ind)

Int input_record (void)

Unsigned char get_current_color (void)

(2) avoid naming functions with meaningless or ambiguous verbs. For example, use process, handle, etc., to name the function, because these verbs do not specify what to do.

(3) the function prototype declaration must be used. Function prototype statements include: references to foreign functions and internal functions, external references must indicate the source of the function on the right: module name and file name; internal functions, as long as comment its definition file name-no comments are required when the caller is in the same file (simple program).

You should ensure that the names and types of parameters in each function declaration are consistent with those in the definition.

5. Naming specification of function parameters

(1) the naming convention of reference variables for parameter names.

(2) in order to improve the running efficiency of the program, reduce the stack occupied by parameters, and transfer the parameters of large structure, pointers or references are used.

(3) in order to make it easier for other programmers to identify whether a pointer parameter is an entry parameter or an exit parameter, and to facilitate the compiler to check for errors, the const flag should be added before the entry parameter.

Such as:. CmCopyString (const CHAR * c_szSource, CHAR * szDest)

6. naming conventions for file names (including dynamic libraries, components, controls, engineering files, etc.)

The naming of the file name requires that the contents of the file be expressed, the length of the file name should not be less than 5 letters, and the use of file names such as file1,myfile is strictly prohibited.

1.2. File naming

File name suffix:

# C language is not tangled with file.h & file.c# C++ Group.1 (note that C is uppercase) file.h & file.C# C++ Group.2file.hh & file.cc# C++ Group.3file.hpp & file.cpp# C++ Group.4file.hxx & file.cxx

There is no choice for tip.1:c language. We will only discuss C++ below.

Tip.2: various combinations can be mixed and matched, such as common file.cpp with file.h and Google style file.cc with file.h

Tip.3: obsessive-compulsive disorder can choose groups that do not mix, so it looks symmetrical.

Tip.4: do not choose the suffix of group 1 uppercase C, especially on case-insensitive operating systems such as Windows

Tip.5: some suffix names may not be supported by some older compilers or IDE by default, for example, vs2005 does not have the extension .hh suffix by default

Tip.6: if you need to cross-platform, it is recommended to choose the third group, at least boost is selected

File name:

# Teddy project UserLog file as an example: # Group.1UserLog.c & TedUserLog.c# Group.2userlog.c & teduserlog.c# Group.3userlog.c & ted_userlog.c# Group.4user_log.c & ted_user_log.c# Group.5user-log.c & ted-user-log.c

Tip.1: if you need to publish the source code directly, you can use the project name as a prefix to prevent file name conflicts during links (msvc seems to automatically rename conflicting .obj files, but cross-platform programs cannot rely on this feature)

Tip.2: there are no obvious drawbacks to the filename style in each group, but note that UserLog.c and userlog.c are two files on case-sensitive systems

1.3. Type naming / redefinition of basic data types, lowercase is more conducive to prolonging the life of Shift than uppercase, but it is also more likely to cause naming conflicts. * / the common style of typedef unsigned char byte;typedef unsigned char byte_t;typedef unsigned char Byte;typedef unsigned char Byte_t;/*** classes and structures is PascalCase, and the weird style of camelCase** is not recommended. * / class HashTable {... class hash_table {... struct FileInfo {... struct file_info {/ * C language common styles and structure names with the suffix'_ t'* / struct fileinfo_t {... struct FileInfo_t {/ * enumerated naming common PascalCase styles * / enum FileFlags {... enum file_flags {.

The tip.1:c language does not have a namespace. To prevent naming conflicts, it is common practice to prefix project names or their abbreviations as type names.

Tip.2: the naming style of classes, structures, and enumerations should be as consistent as possible.

1.4. Namespace naming / * generally uses the project name, depending on the style. * / namespace my_project {... namespace MyProject {...

Tip.1: make sure that namespaces do not conflict with commonly used libraries

1.5. Function and variable naming / * PascalCase,camelCase,** snake_case is a tripod in function and variable naming style, choosing as much as you like. * / void FunctionName (void) {. Void functionName (void) {. Void function_name (void) {. Long VarName;long varName;long var_name;/*** tip.1:snake_case is more readable when the name is longer. * / long variable_names_in_snake_case;long VariableNamesInPascalCase;long variableNamesInCamelCase;/*** tip.2:PascalCase and camelCase have a good distinction in the function, and * * it is not easy to be disturbed by other symbols when quickly scanning the code logic. * / long FabonacciFunction (long rabbitNums) {if (rabbitNums)

< 2) { return rabbitNums; } long resultOne = FabonacciFunction(rabbitNums - 1); long resultTwo = FabonacciFunction(rabbitNums - 2); return resultOne + resultTwo;}long fabonacci_function(long rabbit_nums){ if (rabbit_nums < 2) { return rabbit_nums; } long result_one = fabonacci_function(rabbit_nums - 1); long result_two = fabonacci_function(rabbit_nums - 2); return result_one + result_two;} tip.3：如果类需要兼容标准库迭代器或是要支持range for，begin()和end()函数会破坏PascalCase风格的一致性； 1.6.类成员变量和全局变量命名/*** 类成员变量和全局变量的命名风格和局部变量的命名风格** 并没有更多的区别。唯一的问题是，是否要加前缀或后缀** 以方便和局部变量区分开来。*/class UserInfo { ...private: std::string user_name_; /* Google style */ std::string m_userName; /* Hungarian notation */ /* 不推荐前缀'_'的风格，可能会和标准库命名冲突 */};/* 全局变量要少用，推荐加前缀用于区分 */extern "C" long g_commonCount; tip.1：在有IDE提示时，前缀"m_"的类成员变量能够很快被找到，如果不喜欢这种风格，"this->

"it's also very convenient.

1.7. Constant and enumerated value naming / constant and enumerated value naming style it is recommended to distinguish the naming style of constant and enumerated values from the naming style of local variables. * * the common styles are all-letter capitalization plus'_ 'style, PascalCase style, and * * Google plus' k 'prefix style. * / static const int DAYS_IN_WEEK = 7 th static const int kDaysInWeek = 7 th Enum FileOpenMode {ReadOnly, WriteOnly, ReadWrite}; enum FileOpenMode {READ_ONLY, WRITE_ONLY, READ_WRITE}

Tip.1: if you can use the cantilever 11 feature, enum class is recommended, otherwise you can repeat the name of the enumerated type in the ambiguous enumeration value

1.8. Macro naming / * it is recommended to use all-letter uppercase plus'_ 'delimited style * / # define OS_UNIX#define OS_LINUX#define OS_WINNT/* unless you want to use conditional compilation to make some features optional * / # ifdef USE_TCMALLOC#define my_malloc tcmalloc#else#define my_malloc malloc#endif

Tip.1: try to use constants where you can replace macros with constants.

This is the end of the introduction to the naming conventions and common naming methods of C language and C++. Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.