Google C + + naming conventions

6. Naming conventions

The most important consistency rule is naming management. The naming style quickly learns what the name represents: type? Variable? Function? Constant? Macro...? You don't even need to find a type declaration. The pattern matching engine in our brains can handle these naming conventions very reliably.

Naming rules are arbitrary, but they are more consistent than they are by personal preference, so no matter what you think, the rules are always the rules.

6.1. Universal Naming conventions

Tip

function naming, variable naming, file naming should be descriptive; less abbreviations.

As much as possible to give a descriptive name, do not love the space, after all, let the code easy to understand the new reader is important. Don't use abbreviations that only project developers can understand, and don't abbreviate words by cutting down a few letters.

Price_count_reader;    //No abbreviation num_errors//"num" would have been very common num_dns_connections//Everyone knows what "DNS" is     

Warning

n;                     //inexplicable. nerr//strange abbreviation. N_comp_conns//strange abbreviation. wgc_connections//Only your team knows what it means. There are too many possible explanations for the Pc_reader//"PC". cstmr_id//Some letters have been truncated. 

6.2. File naming

Tip

File names are all lowercase and can contain underscores ( _ ) or hyphens ( - ). By project contract. If there is no project contract, "_" is better.

Acceptable file names:

* my_useful_class.cc* my-useful-class.cc* myusefulclass.cc* muusefulclass_test.cc//' _unittest ' and ' _regtest ' are deprecated.

The C + + file ends with a .cc header file .h . The file that is specifically inserted into the text is .inc terminated, see: Ref:self-contained headers.

Do not use /usr/include a file name that already exists under (Yang.y Note: The path of the compiler to search for the system header file), such as db.h .

You should always try to make the file name more explicit. http_server_logs.hIt's better than that logs.h . When you define a class, the file name usually appears in pairs, such as foo_bar.h and foo_bar.cc , corresponding to the class FooBar .

Inline functions must be placed in a .h file. If the inline function is shorter, it is placed directly in .h .

6.3. Type naming

Tip

The first letter of each word of the type name is capitalized and does not contain underscores: MyExcitingClass MyExcitingEnum .

All types are named-class, struct, type definition (typedef ), enumeration-all use the same convention. For example: /p>

Classes and structs ... ... ... //typedefshash_map<*stringpropertiesmap;  Enums            ...

6.4. Variable naming

Tip

The variable names are lowercase, and the words are concatenated with underscores. The member variable of the class ends with an underscore, but the struct is not used, such as: a_local_variable ,, a_struct_data_member a_class_data_member_ .

Common variable Name:

Example:

string table_name;  Available-underline. String TableName;   Available-All lowercase.

Warning

TableName;   //difference-mixed case. 

Class data members:

Whether static or non-static, class data members can be the same as normal variables, but are underlined.

{  privatetable_name_tablename_Pool<tableinfoPool_//May. };

struct-Body variables:

Whether static or non-static, struct data members can be the same as normal variables without being underlined like a class:

{    namenum_entries;}   

The discussion of structs and classes refers to the structure vs. classes section.

Global variables:

There is no special requirement for global variables, but it is good to use them sparingly, but if you want to use them, you can g_ prefix them with other flags to better differentiate local variables.

6.5. Constant naming

Tip

Before the constant name in the global or class, add k : Kdaysinaweek. And the beginning of each word except the beginning of the k letter is capitalized.

All compile-time constants, whether local, global or class, are slightly different from other variables. kwords that begin with a capital letter followed by:

7;

This rule applies to local scope constants at compile time, but it is also possible to name them by variable rules.

6.6. Function naming

Tip

Regular functions use case blending, and the value and value functions require matching with the variable name:, MyExcitingFunction() , MyExcitingMethod() my_exciting_member_variable() , set_my_exciting_member_variable() .

General functions:

The first letter of each word of the function name is capitalized and is not underlined.

If you have a function that is going to crash directly when it goes wrong, add Ordie to the function name. However, the function itself must be integrated into the product code, and it may also be error-prone.

Addtableentry()deleteurl()openfileordie(     )

Value and SetPoint functions:

The value (accessors) and set value (mutators) functions are matched to the variable names accessed. Here is an excerpt of a class, which num_entries_ is an instance variable of the class:

 class myclass {public: int num_entries () const {return num_entries_} void set_num_entries (int span class= "n" >num_entries) {num_entries_ = num_entries} private: int num_entries_               

Other very short inline function names can also be in lowercase letters, for example. If you call such a function in a loop, you don't even have to cache its return value, the lowercase name is acceptable.

6.7. Name space naming

Tip

Namespaces are named in lowercase letters and based on the project name and directory structure: google_awesome_project .

For a discussion of namespaces and how to name them, refer to the Namespaces section.

6.8. Enumeration naming

Tip

The name of the enumeration should be consistent with constants or macros: kEnumName or ENUM_NAME .

Individual enumeration values should take precedence over the naming of constants. But the name of the macro method is also acceptable. The enumeration name UrlTableErrors (and AlternateUrlTableErrors ) is the type, so the case is mixed in the same way.

{    0kerroroutofmemorykerrormalformedinput,};  012,};         

Until January 2009, we have been recommending the use of macros to name enumeration values. Because of the naming conflict between the enumeration values and macros, there are a number of problems that directly result. As a result, the name of the constant style is preferred instead. The new code should use the constant style as preferentially as possible. But the old code doesn't have to switch to a constant style unless the macro style does produce a compile-time problem.

6.9. Macro naming

Tip

You're not going to: Ref: Use macro <preprocessor-macros>, right? If you must use, name it like this: MY_MACRO_THAT_SCARES_SMALL_CHILDREN .

Reference: Ref: preprocessing macros <preprocessor-macros>; Macros should not normally be used. If it has to be used, its name is all capitalized as the enumeration name, using underscores:

#define ROUND (x) ... #define PI_ROUNDED 3.0

6.10. Special cases of naming conventions

Tip

If you are naming an entity similar to an existing C + + entity, you can refer to the current naming policy.

bigopen():

function name, open() form of reference

uint:

typedef

bigpos:

struct or class , pos the form of the reference

sparse_hash_map:

STL-like entities, referencing STL naming conventions

LONGLONG_MAX:

constants, as INT_MAX

Google C + + naming conventions