I'm using the code-C + + programming specification-naming convention

The naming convention I use is Google's specification, and the following is excerpted from the Google CPP style guide.

The most important consistency rule is named management, and the naming style directly determines that named entities are: types, variables, functions, constants, macros, and so on, without looking up entity declarations, and the pattern matching engine in our brains relies on these naming conventions.
Naming rules are arbitrary, but consistency is more important than naming according to personal preference, so no matter what you think, the rules are always the 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, function names can be "imperative" verbs.

How to Name:
Give as much descriptive a name as possible, do not save space, let others quickly understand your code more important, good naming choices:

int num_errors;                               // Good.int num_completed_connections;   // Good.

Ugly names use vague abbreviations or random characters:

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

Types and variable names are generally nouns: such as Fileopener, Num_errors.
Function names are usually prescriptive, such as OpenFile (), Set_num_errors (), and the access function needs to be described more carefully, matching the variables it accesses.

Abbreviation:
Do not use abbreviations unless you are in the project and are very clear, 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 names are all lowercase and can contain underscores (_) or short lines (-), as specified by the project.
Acceptable file names:
my_useful_class.cc
my-useful-class.cc
myusefulclass.cc
C + + files end With. cc, and header files end with. H.
Do not use file names that already exist under/usr/include (translator note, for UNIX, Linux, etc.), such as Db.h.
In general, try to make the file name more explicit, Http_server_logs.h is better than logs.h, the definition of the class when the file name is generally paired, 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 the. h. If your code is long, you can put it in a file that ends in-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.

3. Type name (Names)
Type name each word starts with an uppercase letter and does not contain underscores: Myexcitingclass, Myexcitingenum.
All types are named-classes, structs, type definitions (typedef), enumerations-using the same conventions, for example:

// classes and structsclass UrlTable { ...class UrlTableTester { ...struct UrlTableProperties { …// typedefstypedef hash_map<UrlTableProperties *, string> PropertiesMap;// enumsenum UrlTableErrors { …

4. Variable naming (Variable Names)
Variable names are lowercase, the words are underlined, and the member variables of the class end with an underscore, such as my_exciting_local_variable, my_exciting_membervariable.

Common variable Name:
Example:

string table_name;   // OK - uses underscore.string tablename;     // OK - all lowercase.string tableName;    // Bad - mixed case.

Class data members:
A struct's data member can be the same as a normal variable without being underlined like a class:

struct UrlTableProperties {  string name;  int num_entries;}

Global variables:
There is no special requirement for global variables, it is good to use less, you can prefix g_ or other flags that are easily distinguishable from local variables.

5. Constant naming (Constant Names)
Add K:kdaysinaweek before the name.
All compile-time constants (whether local, global, or class) are slightly different from other variables, and K is followed by a word that begins with an uppercase letter:

const int kDaysInAWeek = 7;

6. Function naming (Functions Names)
The normal function (regular functions, translator note, which is relative to special functions such as access functions) is mixed in case, and the access function (accessors and mutators) is required to match the variable name: Myexcitingfunction (), Myexcitingmethod (), my_exciting_member_variable (),
Set_my_exciting_member_variable ().

Common functions:
The function name starts with an uppercase letter, with each word capitalized and without an underscore:
Addtableentry ()
DeleteUrl ()

Access function:
The access function is matched to the variable name of the access, which extracts a class that has the instance variable Num_entries_:

class MyClass {public:    ...  int num_entries() const { return num_entries_; }  void set_num_entries(int num_entries) { num_entries_ = num_entries; }private:  int num_entries_;};

Other short inline function names can also use lowercase letters, for example, calling such a function in a loop does not even need to cache its value, and a lowercase name can be accepted.
Note: From this point, it can be seen that the lowercase function name means that it can be used directly inline.

7. Namespaces (Namespace Names)
The name of the namespace is all lowercase and is named based on the project name and directory structure: Google_awesome_project.

8. Enumeration naming (enumerator Names)
The enumeration values should all be uppercase and the words are underlined: my_exciting_enum_value.
Enumeration names are of type, so mixed case: Urltableerrors.

enum UrlTableErrors {  OK = 0,  ERROR_OUT_OF_MEMORY,  ERROR_MALFORMED_INPUT,};

9. Macro naming (Names)
You're not going to use a macro, are you? If used, like this: My_macro_that_scares_small_children.
Refer to pre-processing macros, usually without using macros, and if you absolutely want to use them, the names are all uppercase and underlined like enumeration names:

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

10. Naming rule exceptions (Exceptions to naming rules)
You can refer to an existing naming convention when you name an object that is similar to an existing C + + entity:
Bigopen ()
Function name, reference open ()
UInt
typedef type Definition
Bigpos
struct or class, reference pos
Sparse_hash_map
STL-like entities, reference to STL naming conventions
Longlong_max
constants, similar to Int_max

————————————————————————————————
Translator: Naming conventions are relatively easy to follow, in compliance with code consistency, readability, and slightly arbitrary:

1. General rules: Do not arbitrarily abbreviated, if said Changelocalvalue writing Chglocval also love can original words, modifyplayername writing mdfplynm is too much, except the function name can be appropriate for the verb, other names as far as possible to use clear and understandable nouns ；
2. macros, enumerations, etc. use all caps + underscores;
3. Variables (including classes, struct member variables), files, namespaces, accessor functions, etc. use all lowercase + underscores, class member variables end with an underscore, and global variables start with g_;
4. Common functions, types (with classes and structs, enumeration types), constants, and so on are mixed with case, without underscores;
5. Refer to existing or similar naming conventions.

I'm using the code-C + + programming specification-naming convention