Google C + + programming style Guide (v): naming convention

1. General rules: do not arbitrarily abbreviated; 2. macros, enumerations, etc. use all uppercase + underscores; 3. variables (including class, struct member variables), files, namespaces, access functions, and so use all lowercase + underline, class member variables following the end of the underscore, the global variable begins with g_; 4. Refer to existing or similar naming conventions ...

Naming conventions

The most important consistency rule is naming management, which directly determines which naming entities are: types, variables, functions, constants, macros, and so on, and that the pattern-matching engine in our brain relies on these naming conventions without looking for entity declarations.

Naming rules are arbitrary, but consistency is more important than personal preference, so whatever you think, rules are always rules.

1. Universal Naming Convention (general naming rules)

function naming, variable naming, file naming should be descriptive, not overly abbreviated, types and variables should be nouns, and function names can be "imperative" verbs.

How to Name:

Give descriptive names as much as possible, do not save space, let others quickly understand your code is more important, good naming options:

int num_errors; Good.

int num_completed_connections; Good.

The ugly name uses vague abbreviations or arbitrary characters:

int n; // Bad - meaningless.
int nerr; // Bad - ambiguous abbreviation.
int n_comp_conns; // Bad - ambiguous abbreviation.

Type and variable names are generally nouns: such as Fileopener, Num_errors.

The function name is usually prescriptive, such as OpenFile (), Set_num_errors (), and the access function needs to be described more carefully to match the variables it accesses.

Abbreviation:

Do not use abbreviations unless they are placed outside the project, for example:

// Good
// These show proper names with no abbreviations.
int num_dns_connections; // Most people know what "DNS" stands for.
int price_count_reader; // OK, price count.Makes sense.// Bad!
// Abbreviations can be confusing or ambiguous outside a small group.
int wgc_connections; // Only your group knows what this stands for.
int pc_reader; // Lots of things can be abbreviated "pc".

Do not use abbreviations that omit letters:

int error_count; Good.int error_cnt; Bad.

2. Document naming (file Names)

File name to all lowercase, you can include an underscore (_) or a short line (-), according to the project agreement.

Acceptable file naming:

my_useful_class.cc
my-useful-class.cc
myusefulclass.cc

C + + file ends with. cc, header file ends with. H.

Do not use file names that already exist under/usr/include (for systems such as UNIX, Linux, etc.), such as Db.h.

In general, as much as possible to make the filename more clear, http_server_logs.h is better than logs.h, the definition of a class file name generally appear in pairs, such as foo_bar.h and foo_bar.cc, corresponding class Foobar.

Inline functions must be placed in the. h file, and if the inline function is shorter, it is placed directly in. h. If the code is longer, you can put it in a file that ends with-inl.h. For classes that contain a large number of inline code, you can have three files:

url_table.h // The class declaration.
url_table.cc // The class definition.
url_table-inl.h // Inline functions that include lots of code.

Refer to the first-inl.h document section.