Google C+编程风格指南(五)：命名约定.docVIP

Google C++编程风格指南（五）：命名约定 64位平台C/C++开发注意事项 在/en/l/上例出了28个在64位平台上使用C/C++开发的注意事项，对于进入64位时代的程序员应该去看看这28个事项，这些英文读物对于有C/C++功底的朋友读起来应该并不难，我估计大约20-30分钟可以精读完一篇（或者更快），下面是这28个注意事项的列表。相信对大家一点有帮助。Bhui2014 Lesson 01. What 64-bit systems are. Lesson 02. S 系列文章索引：《Google C++编程风格指南》 命名约定 最重要的一致性规则是命名管理，命名风格直接可以直接确定命名实体是：类型、变量、函数、常量、宏等等，无需查找实体声明，我们大脑中的模式匹配引擎依赖于这些命名规则。命名规则具有一定随意性，但相比按个人喜好命名，一致性更重要，所以不管你怎么想，规则总归是规则。1. 通用命名规则（General Naming Rules）函数命名、变量命名、文件命名应具有描述性，不要过度缩写，类型和变量应该是名词，函数名可以用 命令性 动词。如何命名： 尽可能给出描述性名称，不要节约空间，让别人很快理解你的代码更重要，好的命名选择：int num_errors; // G num_completed_connections; // Good.丑陋的命名使用模糊的缩写或随意的字符：int n; // Bad - nerr; // Bad - ambiguous n_comp_conns; // Bad - ambiguous abbreviation.类型和变量名一般为名词：如FileOpener、num_errors。 函数名通常是指令性的，如OpenFile()、set_num_errors()，访问函数需要描述的更细致，要与其访问的变量相吻合。 缩写： 除非放到项目外也非常明了，否则不要使用缩写，例如：// Good// These show proper names with no num_dns_connections; // Most people know what DNS stands price_count_reader; // OK, price count. Makes sense.// Bad!// Abbreviations can be confusing or ambiguous outside a small wgc_connections; // Only your group knows what this stands pc_reader; // Lots of things can be abbreviated pc .不要用省略字母的缩写：int error_count; // G error_cnt; // Bad.2. 文件命名（File Names） 文件名要全部小写，可以包含下划线（_）或短线（-），按项目约定来。可接受的文件命名：my_useful_class.cc my-useful-class.cc myusefulclass.ccC++文件以.cc结尾，头文件以.h结尾。不要使用已经存在于/usr/include下的文件名（译者注，对UNIX、Linux等系统而言），如db.h。通常，尽量让文件名更加明确，http_server_logs.h就比logs.h要好，定义类时文件名一般成对出现，如foo_bar.h和foo_bar.cc，对应类FooBar。内联函数必须放在.h文件中，如果内联函数比较短，就直接放在.h中。如果代码比较长，可以放到以-inl.h结尾的文件中。对于包含大量内联代码的类，可以有三个文件：url_table.h // The class declaration.url_table.cc // The class definition.url_table-inl.h // Inline functions that include lots of code.参考第一篇-inl.h文件一节。3. 类型命名（Type Names）类型命名每个单词以大写字母开头，不包含下划线：MyExcitingClass、MyExcitingEnum。所有类型命名 类、结构体、类型定义（typedef）、枚举 使用相同约定，例如：// classes and structsclass UrlTable { ... class UrlTableTester { ... struct UrlTableProperties { ...// typedefstypedef hash_map UrlTableProperties *, string Prop