Google C + + style guide Naming conventions go

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.

Universal Naming conventions

Tip    "命令性" 动词.

How to name: Give descriptive names as much as possible. Don't save space and make it more important for others to quickly understand your code. A good naming style:

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

Bad naming uses 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: for example FileOpener , num_errors .

Function names are usually prescriptive (they should be exactly what they should be), such OpenFile() as set_num_errors() . The accessor is a special case (described in detail in: Ref:), with the same name as 函数命名 <function-names> the variable to which it is to be evaluated.

Abbreviation: Do not use unless the abbreviation is very common elsewhere. For example:

            // Good            show proper names with no abbreviations. int num_dns_connections; // 大部分人都知道 "DNS" 是啥意思. int price_count_reader; // OK, price count. 有意义.

          Warning                // 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".

永远不要用省略字母的缩写:

            int error_count;  // Good.            int error_cnt;    // Bad.

File naming

Tip    文件名要全部小写, 可以包含下划线 (``_``) 或连字符 (``-``). 按项目约定来.

Acceptable file names:

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

The C + + file ends with a .cc header file .h .

Do not use /usr/include a file name that already exists under (Yospaly 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 . If the code is longer, you can put it in -inl.h the file that ends. For classes that contain a large number of inline code, you can use 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.

Reference: Ref: -inl.h 文件 <inl-files> section.

Type naming

Tip    ``MyExcitingClass``, ``MyExcitingEnum``.

All types are named--classes, structs, type definitions ( typedef ), enumerations--all using the same conventions. For example:

        // classes and structs        class UrlTable { ...        class UrlTableTester { ... struct UrlTableProperties { ... // typedefs typedef hash_map<UrlTableProperties *, string> PropertiesMap; // enums enum UrlTableErrors { ...

Variable naming

Tip    变量名一律小写, 单词之间用下划线连接. 类的成员变量以下划线结尾, 如::        my_exciting_local_variable        my_exciting_member_variable_

Common variable Naming: example::

        string table_name;  // OK - uses underscore.        string tablename;   // OK - all lowercase.

     Warning            string tableName;   // Bad - mixed case.

struct variables: The data members of a struct can be the same as normal variables without being underlined like a class:

            struct UrlTableProperties {                string name;                int num_entries;            }

Structure and class discussion reference: Ref: 结构体 vs. 类 <structs_vs_classes> section.

Global variables: There is no special requirement for global variables, but it is good to use less, but if you want to use, you can use g_ or other flags as a prefix to better distinguish local variables.

Constant naming

Tip    ``k``: kDaysInAWeek.

All compile-time constants, whether local, global or class, are slightly different from other variables. kWord followed by uppercase letters:: const int kdaysinaweek = 7;

function naming

Tip    ``MyExcitingFunction()``, ``MyExcitingMethod()``, ``my_exciting_member_variable()``, ``set_my_exciting_member_variable()``.``常规函数: 函数名的每个单词首字母大写, 没有下划线::

    AddTableEntry()    DeleteUrl()

  values and SetPoint functions: The value and the set function are matched to the variable names accessed. Here is an excerpt of a class,  "num_entries_< Span class= "Hljs-string" is an instance variable of the class:    

        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_; };

其它非常短小的内联函数名也可以用小写字母, 例如. 如果你在循环中调用这样的函数甚至都不用缓存其返回值, 小写命名就可以接受.## 名字空间命名

The Tip namespace is named in lowercase letters and is based on the project name and directory structure: google_awesome_project .

关于名字空间的讨论和如何命名, 参考 :ref:`名字空间 <namespaces>` 一节.## 枚举命名

The name of the TIP enumeration should be the same as: Ref: 常量 <constant-names> or: Ref: 宏 <macro-names> Consistent: kEnumName or ENUM_NAME .

单独的枚举值应该优先采用 :ref:`常量 <constant-names>` 的命名方式. 但 :ref:`宏 <macro-names>` 方式的命名也可以接受. 枚举名 ``UrlTableErrors`` (以及 ``AlternateUrlTableErrors``) 是类型, 所以要用大小写混合的方式.

    enum UrlTableErrors {        kOK = 0,        kErrorOutOfMemory,        kErrorMalformedInput,    };    enum AlternateUrlTableErrors {        OK = 0, OUT_OF_MEMORY = 1, MALFORMED_INPUT = 2, };

2009 年 1 月之前, 我们一直建议采用 :ref:`宏 <macro-names>` 的方式命名枚举值. 由于枚举值和宏之间的命名冲突, 直接导致了很多问题. 由此, 这里改为优先选择常量风格的命名方式. 新代码应该尽可能优先使用常量风格. 但是老代码没必要切换到常量风格, 除非宏风格确实会产生编译期问题.## 宏命名

Tip you're not going to: Ref: 使用宏 <preprocessor-macros> , right? If you must, name it like this: MY_MACRO_THAT_SCARES_SMALL_CHILDREN .

`预处理宏 <preprocessor-macros>`; 通常 *不应该* 使用宏. 如果不得不用, 其命名像枚举命名一样全部大写, 使用下划线::

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

## 命名规则的特例

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

 "Bigopen () ": function name, reference open ()  " Typedef " ' Bigpos ' struct ' or ", referring to  " Pos "Sparse_hash_map": STL Similar entities; Refer to the STL naming convention  "Longlong_max": constants, like           

Google C + + style guide Naming conventions go