当前位置:首页 > 工业技术
C++编码规范
C++编码规范

C++编码规范PDF电子书下载

工业技术

  • 电子书积分:10 积分如何计算积分?
  • 作 者:陈世忠编著
  • 出 版 社:北京:人民邮电出版社
  • 出版年份:2002
  • ISBN:7115102864
  • 页数:240 页
图书介绍:本书由300多条C++编程原则组成,融合并提炼了许多人多年开发C++程序积累下来的成熟经验,供读者学习参考。
《C++编码规范》目录
标签:编著 编码

0.1 原因 1

第0章 为什么要用 C++ 1

0.2 语言的发展和代码复用 2

0.3 代码复用的特点 2

0.4 代码复用对我们的影响 3

第1章 命名原则 5

原则1.1 关于类型名 5

原则1.2 关于变量和函数名 6

原则1.3 关于全大写的函数名(建议) 7

原则1.4 关于宏、常量和模板名 9

原则1.6 关于变量名前缀(供参考) 10

原则1.5 关于指针标识符名(供参考) 10

原则1.7 关于匿名命名空间级标识符的前缀 12

原则1.8 减少匿名命名空间级标识符 13

原则1.9 命名时避免使用国际组织占用的格式 14

原则1.10 名字要本着清楚、简单的原则 14

原则1.11 尽量用可发音的名字 15

原则1.12 尽量用英文命名 16

原则1.13 尽量选择通用词汇并贯穿始终 16

原则1.14 避免用模棱两可、晦涩或不标准的缩写 16

原则1.17 建议起名尽量通俗,太专一会限制以后的扩展 17

原则1.15 避免使用会引起误解的词汇 17

原则1.16 减少名字中的冗余信息 17

原则1.18 名字最好尽可能精确地表达其内容 18

原则1.19 避免名字中出现形状混淆的字母或数字 18

原则1.20 命名类和成员使得“object.method()”有意义 18

原则1.21 类和对象名应是名词 19

原则1.22 实现行为的类成员函数名应是动词 19

原则1.23 类的存取和查询成员函数名应是名词或形容词 20

原则1.24 变量名应是名词 20

原则1.26 关于函数的左值参数和右值参数名 21

原则1.25 布尔型的名字要直观 21

原则1.27 避免局部名和外层的名字冲突 22

原则1.28 用 a、an、any 区分重名(参数) 22

原则1.29 模板类型名应有意义 23

第2章 类型的使用 25

原则2.1 避免隐式声明类型 25

原则2.2 慎用无符号类型 25

原则2.3 少用浮点数除非必须 26

原则2.4 用 typedef 简化程序中的复杂语法 26

原则2.6 慎用位操作 27

原则2.7 用 enum 取代(一组相关的)常量 27

原则2.5 少用 union 27

原则2.8 使用内置 bool 类型 28

原则2.9 (尽量)用引用取代指针 28

第3章 函数 31

原则3.1 一定要做到先定义后使用 31

原则3.2 函数原型声明放在一个头文件中 31

原则3.3 函数无参数一定要用 void 标注 31

原则3.4 对于内置类型参数应传值(除非函数内部要对其修改) 32

原则3.5 对于非内置类型参数应传递引用(首选)或指针 32

原则3.6 关于何时用指针传递参数 33

原则3.7 避免使用参数不确定的函数 34

原则3.8 若不得不使用参数不确定的函数,用提供的方法 35

原则3.9 避免函数的参数过多 36

原则3.10 尽量保持函数只有唯一出口 36

原则3.11 显式定义返回类型 36

原则3.12 (非 void)任何情况都要有返回值 37

原则3.13 若函数返回状态,尝试用枚举作类型 37

原则3.14 返回指针类型的函数应该用 NULL 表示失败 38

原则3.15 函数尽量返回引用(而不是值) 38

原则3.16 若必须返回值,不要强行返回引用 39

原则3.18 禁止成员函数返回成员(可读写)的引用或指针 40

原则3.17 当函数返回引用或指针时,用文字描述其有效期 40

原则3.19 重复使用的代码用函数替代 41

原则3.20 关于虚友元函数 41

原则3.21 关于虚构造函数 43

第4章 类的设计和声明 45

原则4.1 类应是描述一组对象的集合 45

原则4.2 类成员应是私有的(private) 45

原则4.3 保持对象状态信息的持续性 46

原则4.4 提高类内聚合度 46

原则4.5 降低类间的耦合度 47

原则4.7 保持类的不同接口在实现原则上的一致性 48

原则4.6 努力使类的接口少而完备 48

原则4.8 保持不同类的接口在实现原则上的一致性 49

原则4.9 避免为每个类成员提供访问函数 50

原则4.10 不要在类定义时提供成员函数体 50

原则4.11 函数声明(而不是实现)时定义参数的缺省值 51

原则4.12 恰当选择成员函数、全局函数和友元函数 51

原则4.13 防范、杜绝潜在的二义性 52

原则4.14 显式禁止编译器自动生成不需要的函数 53

原则4.15 当遇到错误时对象应该应对有度 54

原则4.16 用嵌套类的方法减少匿名命名空间类的数量 54

原则5.1 “公共继承(public inheritance)”意味着“派生类是基类” 55

原则5.2 关于“有”和“由…实现” 55

第5章 (面向对象的)继承 55

原则5.3 关于继承和模板(template)的区别 56

原则5.4 关于继承接口和继承实现 57

原则5.5 限制继承的层数 59

原则5.6 继承树上非叶子节点的类应是虚基类 59

原则5.7 显式提供继承和访问修饰:public、protected 或 private 60

原则5.8 显式指出继承的虚函数 61

原则5.9 基类析构函数(destructor)首选是虚函数 62

原则5.10 绝不要重新定义(继承来的)非虚函数 62

原则5.11 绝不要重新定义缺省参数值 63

原则5.12 不要将基类强制转换成派生类 64

原则5.13 关于 C++中的分支用法选择 64

原则5.14 慎用多重继承 65

原则5.15 所有多重继承的基类析构函数都应是虚函数 66

第6章 内存分配和释放 67

原则6.1 用 new、delete 取代 malloc、calloc、realloc 和 free 67

原则6.2 new、delete 和 new[]、delete[]要成对使用 67

原则6.3 确保所有 new 出来的东西适时被 delete 掉 68

原则6.4 谁申请谁释放 68

原则6.5 当对象消亡时确保指针成员指向的系统堆内存全部被释放 70

原则6.6 自定义类的 new/delete 操作符一定要符合原操作符的行为规范 72

原则6.7 自定义类的 new 操作符一定要自定义类的 delete 操作符 73

原则6.8 当所指的内存被释放后,指针应有一个合理的值 73

原则6.9 记住给字符串结束符申请空间 74

第7章 初始化和清除 75

原则7.1 声明后就初始化强于使用前才初始化 75

原则7.2 初始化要彻底 76

原则7.3 确保每一个构造函数都实现完全的初始化 76

原则7.4 尽量使用初始化列表 77

原则7.5 初始化列表要按成员声明顺序初始化它们 78

原则7.8 拷贝构造函数和赋值函数尽量用常量参数 79

原则7.7 不要用构造函数初始化静态成员 79

原则7.6 构造函数没结束,对象就没有构造出来 79

原则7.9 让赋值函数返回当前对象的引用 80

原则7.10 在赋值函数中防范自己赋值自己 80

原则7.11 拷贝和赋值要确保彻底 81

原则7.12 关于构造函数、析构函数、赋值函数、相等或不等函数的格式 82

原则7.13 为大多数类提供缺省和拷贝构造函数、析构函数、赋值函数、相等函数 83

原则7.14 只有在有意义时才提供缺省构造函数 83

原则7.15 包含资源管理的类应自定义拷贝构造函数、赋值函数和析构函数 84

原则7.16 拷贝构造函数、赋值函数和析构函数要么全自定义,要么全生成 84

原则7.17 类应有自己合理的拷贝原则:或浅拷贝或深拷贝 84

原则7.19 将循环索引的初值定在循环点附近 85

原则7.18 若编译时会完全初始化,不要给出数组的尺寸 85

原则7.20 确保全局变量在使用前被初始化 86

第8章 常量 89

原则8.1 关于常量修饰符的含义 89

原则8.2 在设计函数原型时,对那些不可能被修改的参数用常量修饰 89

原则8.3 类成员可以转换成常量形式暴露出来 90

原则8.4 关于常量成员函数 91

原则8.5 不要让常量成员函数修改程序的状态 92

原则8.6 不要将常量强制转换成非常量 92

原则8.7 任何变量和成员函数,首选用 const 修饰 92

原则9.1 仔细区分带缺省值参数的函数和重载函数 93

第9章 重载 93

原则9.2 确保重载函数的所有版本有共同的目的和相似的行为 94

原则9.3 避免重载在指针和整型类型上 94

原则9.4 尽量避免重载在模板类型上 95

第10章 操作符 97

原则10.1 遵守操作符原本的含义,不要创新 98

原则10.2 确保自定义操作符能和其他操作符混合使用 98

原则10.3 区分作为成员函数和作为友元的操作符 98

原则10.4 关于前后缀操作符 99

原则10.5 确保相关的一组操作符行为统一 100

原则10.6 绝不要自定义 operator ()、operatorll()和 operator,() 100

原则11.2 如果不得不做类型转换,尽量用显式方式 103

第11章 类型转换 103

原则11.1 尽量避免强制类型转换 103

原则11.3 使用新型的类型转换并确保选择正确 104

原则11.4 用虚函数方式取代 dynamic_cast 104

原则11.5 自定义类最好提供显式而不是隐式转换函数 105

原则19.2 关于文件名的选择 106

原则11.6 用关键字 explicit 防止单参数构造函数的类型转换功能 106

原则11.7 限制隐式类型转换的类型数 107

原则11.8 避免多个函数提供相同的类型转换 107

第12章 友元 109

原则12.1 少用友元 109

原则12.2 减少拥有友元特权的个数 109

原则13.1 使用模板如果有限制条件一定要在注释和文档中描述清楚 111

第13章 模板 111

原则13.2 模板类型应传引用/指针而不是值 112

原则13.3 注意模板编译的特殊性 112

原则13.4 嵌套 template的>>中间要加空格以区别于 operator>> 114

第14章 表达式和控制流程 115

原则14.1 让表达式直观 115

原则14.2 避免在表达式中用赋值语句 115

原则14.3 不能将枚举类型进行运算后再赋给枚举变量 116

原则14.4 避免对浮点类型做等于或不等于判断 116

原则14.5 尝试用范围比较代替精确比较 117

原则14.6 范围用包含下限不包含上限方式表示 117

原则14.7 关于 goto 118

原则14.8 在循环过程中不要修改循环计数器 118

原则15.1 彻底用常量替代(类似功能的)宏 121

第15章 宏 121

原则15.2 代码中的数值应由一个有意义的标识符代替 122

原则15.3 若宏值多于一项,一定要使用括号 123

原则15.4 不要用分号结束宏定义 123

原则15.5 彻底用 inline 函数替代(类似功能的)宏函数 123

原则15.6 不好被替代的宏函数 124

原则15.7 函数宏的每个参数都要括起来 125

原则15.8 不带参数的宏函数也要定义成函数形式 125

原则15.9 用{}将函数宏的函数体括起来 126

原则15.10 彻底用 typedef 代替宏定义新类型 127

原则15.12 不要用宏改写语言 128

原则15.11 不要在公共头文件中定义宏 128

第16章 异常(exception)处理 129

原则16.1 确保代码在异常出现时能正确处理 129

原则16.2 正确注释代码的异常处理能力 130

原则16.3 减少不必要的异常处理 130

原则16.4 不要利用异常处理机制处理其他功能 130

原则16.5 注意模板类型可能会破坏异常处理的一些约定 131

原则16.6 确保异常发生后资源还能被回收 132

原则16.7 特别当心析构时发生异常 132

原则16.9 捕捉异常时绝不要先基类后派生类 133

原则16.8 抛出的异常最好是一个对象 133

原则16.10 捕捉异常时用引用 134

原则17.1 水平缩进每次用两个空格 135

第17章 代码格式 135

原则17.2 不要在引用操作符前后加空格 136

原则17.3 不要在单目操作符和其操作对象间加空格 136

原则17.4 不要在“::”前后加空格 137

原则17.5 在“,”“;”之后(而不是之前)加空格 137

原则17.6 在关键字和其后的“(”间加一个空格 137

原则17.7 文件中的主要部分用空行分开 138

原则17.8 函数间要用空行分开 138

原则17.10 用空行将代码按逻辑片断划分 139

原则17.11 可以考虑将 if 块和 else/else if 块用空行分开 139

原则17.9 组局部变量声明和代码之间用空行分开 139

原则17.12 函数返回语句要和其他语句用空行分开 140

原则17.13 每一行不超过78个字符 141

原则17.14 当一条语句超过78个字符时按逻辑划分成不同行 141

原则17.15 花括号{}要单独占一行 142

原则17.16 花括号中没有或只有一条语句时也不省略花括号 144

原则17.17 不要在一行中放多于一条语句 144

原则17.18 语句 switch 中的每个 case 各占一行 145

原则17.19 语句 switch 中的 case 按字母顺序排列 146

原则17.20 为所有 switch 语句提供 default 分支 146

原则17.21 若某个 case 不需要 break 一定要加注释声明 146

原则17.22 变量定义应集中放置、各占一行,并按字母顺序排列 147

原则17.23 定义指针和引用时*和 紧跟类型 148

原则17.24 按编译器解析顺序放置变量声明的修饰符 148

原则17.25 关于函数声明和定义的格式 149

原则17.26 函数名和左括号间不要空格 150

原则17.27 声明函数时给出参数的名字,除非没有用处 150

原则17.28 关于类内不同级别的元素排列顺序 151

原则17.30 类成员变量按字母顺序排列 153

原则17.31 关于静态成员的访问 153

原则17.29 关于类成员函数的排列顺序 153

原则17.32 关于字符常量 154

原则17.33 用带颜色的编辑器 154

第18章 注释 155

原则18.1 用英语写全部的注释 155

原则18.2 确保注释完善你的代码,而不是重复你的代码 155

原则18.6 注释不能超出被注释代码所包含的内容 156

原则18.4 注释中的术语要通用 156

原则18.3 注释用词要精确,不能有二义性 156

原则18.5 注释要简单、清楚、切中要害 156

原则18.7 注释中避免引用容易变化的信息 157

原则18.8 确保所有注释(随代码)及时更新 158

原则18.9 注释不具备约束使用者行为的能力 158

原则18.10 注释不要嵌套 159

原则18.11 不要用/**/注释掉(大块)代码,应该用#if0 159

原则18.12 区分“战略性”注释和“战术性”注释 160

原则18.13 行末注释尽量对齐 160

原则18.16 对每个#else 或#endif 给出行末注释 161

原则18.15 减少不必要的单独占一行的注释 161

原则18.14 单独的注释行和被注释语句缩进相同的空格 161

原则18.17 对每个引用的头文件给出行末注释 162

原则18.18 对每个空循环体给出确认性注释 162

原则18.19 关于函数注释 163

原则18.20 关于注释频率 164

第19章 文件和目录 165

原则19.1 使用统一而且通用的文件名后缀 165

原则19.3 关于文件/目录名的字符集选择 166

原则19.5 关于模板类的文件安排 167

原则19.4 关于每个类的文件组成 167

原则19.6 保持文件前言的简洁性 168

原则19.7 关于文件的段落安排 169

原则19.8 关于目录组织 170

第20章 头文件 171

原则20.1 头文件多次引用的防范 171

原则20.2 确保公共头文件的自足性 172

原则20.3 只引用需要的头文件 172

原则20.4 引用时“”和<>的用法 173

原则20.5 引用头文件的顺序 173

原则20.7 将函数库放在一个单独的目录下引用 174

原则20.6 引用时不要用绝对路径 174

原则20.8 不要在头文件中定义常量/变量 175

原则20.9 任何声明若被多个源文件引用则应在一个头文件中 175

原则20.10 在源文件中不要用关键字 extern 175

第21章 条件编译 177

原则21.1 最小化条件编译的使用范围 177

原则21.2 若使用#if 或#ifdef,不要遗漏#else 179

原则21.3 编译条件的含义要具体 179

原则21.4 对复杂的编译条件用括号使其清晰 180

原则21.5 条件编译和普通条件语句不要混合使用 180

原则21.6 若只测试某符号是否存在,不要给该符号赋值 181

原则22.1 关注编译时的警告(warning)错误 183

原则22.2 把问题尽量暴露在编译时而不是运行时 183

第22章 编译 183

原则22.3 减少文件的依赖程度 184

原则22.4 减少编译时间 185

原则22.5 透彻研究编译器 186

第23章 兼容性 187

原则23.1 遵守 ANSIC 和 ISO C++国际标准 187

原则23.2 将不符合国际标准的代码与其他代码分开 187

原则23.5 注意双字节字符的兼容性 188

原则23.3 不要假设字符类型是否是有符号类型 188

原则23.4 运算时显式转换有符号和无符号类型 188

原则23.6 恰当使用位操作符 189

原则23.7 注意位域(bitfield)变量的兼容性问题 189

原则23.8 不要强制引用/指针指向尺寸不同的目标 189

原则23.9 确保类型转换不会丢失信息 190

原则23.10 不要假设类型的存储尺寸 190

原则23.11 如果一定要规定类型的存储尺寸 191

原则23.12 不要假设对象(等数据结构)的存储结构 191

原则23.13 注意运算溢出问题 192

原则23.15 不要假设函数参数的计算顺序 193

原则23.14 不要假设表达式的运算顺序 193

原则23.16 不要假设不同源文件中静态或全局变量的初始化顺序 194

原则23.17 不要依赖编译器基于实现、未明确或未定义的功能 194

原则23.18 注意数据文件的兼容性 195

原则23.19 注意引用公共库的兼容性 195

原则23.20 一定不要重新实现标准库函数 196

原则23.21 将所有#include 的文件名视为大小写敏感 196

原则23.22 代码中用到的路径只用“/”而不要用“/” 196

原则23.23 确保 main()函数总是返回一个整型 197

原则23.24 不要依赖 pragmas 197

原则24.2 不要用移位代替乘除运算 199

第24章 性能 199

原则24.1 使用性能追踪分析工具 199

原则24.3 如无必要,不要用非 int 的整型类型 200

原则24.4 不要使用关键字 register 200

原则24.5 避免在循环体内部定义对象 200

原则24.6 减少代价很高的对象拷贝 201

原则24.7 减少临时对象 201

原则24.8 注意大尺寸对象数组 202

原则24.9 返回对象(值)的优化 202

原则24.12 恰当地使用 inline 函数 204

原则24.11 恰当使用递归 204

原则24.10 前缀++和--的效率更高 204

原则24.13 虚函数和虚继承效率会有一点损失 206

原则24.14 如果合理,使用编译器生成的函数 207

原则24.15 如果合理,构造直传类 208

原则24.16 关于缓存(cache)类成员 209

原则24.17 关于标准库的性能 209

原则24.18 关于偷懒 209

原则24.19 关于勤快 211

原则24.20 80—20原则 211

原则25.2 确保任何定义只发生一次 213

原则25.1 避免产生全局数据对象 213

第25章 其他 213

原则25.3 指针操作中用 NULL 代替 O 214

原则25.4 不要把 NULL 用在指针以外的领域 214

原则25.5 不要弄巧成拙 214

原则25.6 将不再使用的代码删掉 215

原则25.7 运行时不要改变进程的环境变量 215

原则25.8 该用 volatile 时一定要用 215

原则25.9 不要使用鲜为人知的替换符号 216

原则25.10 关于代码审查(code inspection/review)规范 216

附录 供参考的源代码 219

返回顶部