google_c编程风格指南_中文版_3.133.docVIP

Google C++编程风格指南 译者前言 Google经常会发布一些开源项目，意味着会接受来自其他代码贡献者的代码；但是如果代码贡献者的编程风格与Google的不一致，会给代码阅读者和其他代码提交这造成不小的困扰；Google 因此发布了这份自己的编程风格，使所有提交代码的人都能获知Google 的编程风格。 翻译初衷： 规则的作用就是避免混乱；但规则本身一定要权威，有说服力，并且是理性的；我们所见过的大部分编程规范，其内容或不够严谨，或阐述过于简单，或带有一定的武断性。 Google 保持其一贯的严谨精神，5万汉字的指南涉及广泛，论证严密；我们翻译该系列指南的主因也正是其严谨性；严谨意味着指南的价值不仅仅局限于它罗列出的规范，更具参考意义的是它为了列出规范而做的谨慎权衡过程。 指南不仅列出你要怎么做，还告诉你为什么要这么做，哪些情况下可以不这么做，以及如何权衡其利弊；其他团队未必要完全遵照指南亦步亦趋，如前面所说，这份指南是Google根据自身实际情况打造的，适用于其主导的开源项目；其他团队可以参照该指南，或从中汲取灵感，建立适合自身实际情况的规范。 我们在翻译的过程中，收获颇多；希望本系列指南中文版对你同样能有所帮助。 我们翻译时也是尽力保持严谨，但水平所限，bug 在所难免；有任何意见或建议，可与我们取得联系。 中文版和英文版一样，使用Artistic License/GPL开源许可。 中文版修订历史：2009-06 3.133：YuleFox 的1.0 版已经相当完善，但原版在近一年的时间里，其规范也发生了一些变化。yospaly 与 YuleFox 一拍即合，以项目的形式来延续中文版： Google 开源项目风格指南 - 中文版项目； 主要变化是同步到 3.133 最新英文版本，做部分勘误和改善可读性方面的修改，并改进排版效果；yospaly 重新翻修，YuleFox 做后续评审。2008-07 1.0 ：出自 YuleFox 的 Blog，很多地方摘录的也是该版本。 背景 C++ 是Google 大部分开源项目的主要编程语言正如每个C++ 程序员都知道的C++ 有很多强大的特性但这种强大不可避免的导致它走向复杂使代码更容易产生 bug难以阅读和维护 本指南的目的是通过详细阐述 C++ 注意事项来驾驭其复杂性. 这些规则在保证代码易于管理的同时, 高效使用 C++ 的语言特性. 风格, 亦被称作可读性, 也就是指导 C++ 编程的约定. 使用术语 “风格” 有些用词不当, 因为这些习惯远不止源代码文件格式化这么简单. 使代码易于管理的方法之一是加强代码一致性. 让任何程序员都可以快速读懂你的代码这点非常重要. 保持统一编程风格并遵守约定意味着可以很容易根据 “模式匹配” 规则来推断各种标识符的含义. 创建通用, 必需的习惯用语和模式可以使代码更容易理解. 在一些情况下可能有充分的理由改变某些编程风格, 但我们还是应该遵循一致性原则，尽量不这么做. 本指南的另一个观点是 C++ 特性的臃肿. C++ 是一门包含大量高级特性的庞大语言. 某些情况下, 我们会限制甚至禁止使用某些特性. 这么做是为了保持代码清爽, 避免这些特性可能导致的各种问题. 指南中列举了这类特性, 并解释为什么这些特性被限制使用. Google 主导的开源项目均符合本指南的规定. 注意: 本指南并非 C++ 教程, 我们假定读者已经对 C++ 非常熟悉. 1. 头文件 通常每一个 .cc 文件都有一个对应的 .h 文件. 也有一些常见例外, 如单元测试代码和只包含 main() 函数的 .cc 文件. 正确使用头文件可令代码在可读性、文件大小和性能上大为改观. 下面的规则将引导你规避使用头文件时的各种陷阱. 1.1. #define 保护 Tip 所有头文件都应该使用 #define 防止头文件被多重包含, 命名格式当是: PROJECT_PATH_FILE_H_ 为保证唯一性, 头文件的命名应该依据所在项目源代码树的全路径. 例如, 项目 foo 中的头文件 foo/src/bar/baz.h 可按如下方式保护: #ifndef FOO_BAR_BAZ_H_ #define FOO_BAR_BAZ_H_ … #endif // FOO_BAR_BAZ_H_ 1.2. 头文件依赖 Tip 能用前置声明的地方尽量不使用 #include. 当一个头文件被包含的同时也引入了新的依赖, 一旦该头文件被修改, 代码就会被重新编译. 如果这个头文件又包含了其他头文件, 这些头文件的任何改变都将导致所有包含了该头文件的代码被重新编译. 因此, 我们倾向于减少包含头文件, 尤其是在头文件中包含头文件. 使用前置声明可以显著减少需要包含的头文件数量. 举例说明: