您的位置:首页 > 编程语言 > C语言/C++

Google C++ 风格指南(转载)

2009-11-29 22:51 323 查看
 

Google C++ 风格指南 - 中文版

版本:3.133
原作者:Benjy Weinberger
Craig Silverstein
Gregory Eitzmann
Mark Mentovai
Tashana Landray

翻译:YuleFox
yospaly

项目主页:Google Style Guide

Google 开源项目风格指南 - 中文版

目录

Contents
Google C++ 风格指南 - 中文版
目录

译者前言

背景

1. 头文件
1.1. #define 保护

1.2. 头文件依赖

1.3. 内联函数

1.4. -inl.h文件

1.5. 函数参数的顺序

1.6. #include 的路径及顺序

译者 (YuleFox) 笔记

2. 作用域
2.1. 名字空间
2.1.1. 匿名名字空间

2.1.2. 具名的名字空间

2.2. 嵌套类

2.3. 非成员函数, 静态成员函数, 和全局函数

2.4. 局部变量

2.5. 静态和全局变量

译者 (YuleFox) 笔记

3. 类
3.1. 构造函数的职责

3.2. 默认构造函数

3.3. 显式构造函数

3.4. 拷贝构造函数

3.5. 结构体 VS. 类

3.6. 继承

3.7. 多重继承

3.8. 接口

3.9. 运算符重载

3.10. 存取控制

3.11. 声明顺序

3.12. 编写简短函数

译者 (YuleFox) 笔记

4. 来自 Google 的奇技
4.1. 智能指针

4.2. cpplint

5. 其他 C++ 特性
5.1. 引用参数

5.2. 函数重载

5.3. 缺省参数

5.4. 变长数组和 alloca()

5.5. 友元

5.6. 异常

5.7. 运行时类型识别

5.8. 类型转换

5.9. 流

5.10. 前置自增和自减

5.11. const 的使用

5.12. 整型

5.13. 64 位下的可移植性

5.14. 预处理宏

5.15. 0 和 NULL

5.16. sizeof

5.17. Boost 库

6. 命名约定
6.1. 通用命名规则

6.2. 文件命名

6.3. 类型命名

6.4. 变量命名

6.5. 常量命名

6.6. 函数命名

6.7. 名字空间命名

6.8. 枚举命名

6.9. 宏命名

6.10. 命名规则的特例

7. 注释
7.1. 注释风格

7.2. 文件注释

7.3. 类注释

7.4. 函数注释

7.5. 变量注释

7.6. 实现注释

7.7. 标点, 拼写和语法

7.8. TODO 注释

译者 (YuleFox) 笔记

8. 格式
8.1. 行长度

8.2. 非 ASCII 字符

8.3. 空格还是制表位

8.4. 函数声明与定义

8.5. 函数调用

8.6. 条件语句

8.7. 循环和开关选择语句

8.8. 指针和引用表达式

8.9. 布尔表达式

8.10. 函数返回值

8.11. 变量及数组初始化

8.12. 预处理指令

8.13. 类格式

8.14. 初始化列表

8.15. 名字空间格式化

8.16. 水平留白

8.17. 垂直留白

译者 (YuleFox) 笔记

9. 规则特例
9.1. 现有不合规范的代码

9.2. Windows 代码

10. 结束语

译者前言

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++ 非常熟悉.
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息