华为C++语言通用编程规范

上传人:飞****9 文档编号:127579827 上传时间:2020-04-03 格式:PDF 页数:66 大小:926.12KB
返回 下载 相关 举报
华为C++语言通用编程规范_第1页
第1页 / 共66页
华为C++语言通用编程规范_第2页
第2页 / 共66页
华为C++语言通用编程规范_第3页
第3页 / 共66页
华为C++语言通用编程规范_第4页
第4页 / 共66页
华为C++语言通用编程规范_第5页
第5页 / 共66页
点击查看更多>>
资源描述

《华为C++语言通用编程规范》由会员分享,可在线阅读,更多相关《华为C++语言通用编程规范(66页珍藏版)》请在金锄头文库上搜索。

1、 章节 内容 0 前言 目的 重点关注 约定 例外 1 原则 好代码的原则 类和函数设计指导原则 保证静态类型安全 遵循 C ISO 标准 优先编译时检查错误 使用命名空间来限定作用域 优先使用 C 特 性而不是 C 特性 2 命名 通用命名 文件命名 函数命名 类型命名 变量命名 宏 常量 枚举命名 3 格式 行宽 缩进 大括号 函数声明和定义 函数调用 if 语句 循环语句 switch 语 句 表达式 变量赋值 初始化 指针和引用 编译预处理 空格和空行 类 4 注释 注释风格 文件头注释 函数头注释 代码注释 5 头文件 头文件职责 头文件依赖 6 作用域 命名空间 全局函数和静态成员

2、函数 全局变量 全局常量和静态成员常量 7 类 构造 拷贝构造 赋值和析构函数 继承 多重继承 重载 8 函数 函数设计 内联函数 函数参数 9 C 其 他特性 常量与初始化 表达式 类型转换 资源分配和释放 标准库 const 的用法 异 常 模板 宏 10 现代 C 特性 代码简洁性和安全性提升 智能指针 Lambda 接口 0 前言前言 目的目的 规则并不是完美的 通过禁止在特定情况下有用的特性 可能会对代码实现造成影 响 但是我们制定规则的目的 为了大多数程序员可以得到更多的好处 如果 在团队运作中认为某个规则无法遵循 希望可以共同改进该规则 参考该规范之前 希望您具有相应的 C 基础

3、能力 而不是通过该文档来学习 C 1 了解 C 的 ISO 标准 2 熟知 C 的基本语言特性 包括 C 03 11 14 17 相 关特性 3 了解 C 的标准库 重点关注重点关注 1 约定 C 的编程风格 比如命名 排版等 2 C 的模块化设计 如何设计头文件 类 接口和函数 3 C 相关特性的优秀实践 比如常量 类型转换 资源管理 模板等 4 现代 C 的优秀实践 包括 C 11 14 17 中可以提高代码可维护性 提高代 码可靠性的相关约定 约定约定 规则规则 编程时必须遵守的约定 must 建议建议 编程时应该遵守的约定 should 本规范适用通用 C 标准 如果没有特定的标准版本

4、 适用所有的版本 C 03 11 14 17 例外例外 无论是 规则 还是 建议 都必须理解该条目这么规定的原因 并努力遵守 但是 有些规则和建议可能会有例外 在不违背总体原则 经过充分考虑 有充足的理由的前提下 可以适当违背规范中 约定 例外破坏了代码的一致性 请尽量避免 规则 的例外应该是极少的 下列情况 应风格一致性原则优先 修改外部开源代码 第三方代码时 应该遵守开源代码 第三方代码已有规范 修改外部开源代码 第三方代码时 应该遵守开源代码 第三方代码已有规范 保持风格统一 保持风格统一 某些特定领域 优先参考其行业规范 某些特定领域 优先参考其行业规范 1 原则原则 好代码的原则好代

5、码的原则 我们参考 Kent Beck 的简单设计四原则来指导我们的如何写出优秀的代码 如何有 效地判断我们的代码是优秀的 1 通过所有测试 Passes its tests 2 尽可能消除 重复 Minimizes duplication 3 尽可能清晰表达 Maximizes clarity 4 更少代码元 素 Has fewer elements 5 以上四个原则的重要程度依次降低 这组定义被称做简 单设计原则 第一条强调的是外部需求 这是代码实现最重要的 第二点就是代码的模块架构设 计 保证代码的正交性 保证代码更容易修改 第三点是代码的可阅读性 保证代 码是容易阅读的 最后一点才是保

6、证代码是简洁的 在简洁和表达力之间 我们更 看重表达力 类和函数设计指导原则类和函数设计指导原则 C 是典型的面向对象编程语言 软件工程界已经有很多 OOP 原则来指导我们编 写大规模的 高可扩展的 可维护性的代码 高内聚 低耦合的基本原则 SOLID 原则 迪米特法则 Tell Don t ask 原则 组合 聚合复用原则 保证静态类型安全保证静态类型安全 我们希望 C 应该是静态类型安全的 这样可以减少运行时的错误 提高代码的健 壮性 但是由于 C 的下面的特性存在 会破坏 C 静态类型安全 我们针对这部 分特性要仔细处理 unions 联合体 类型转换 cast 缩窄转换 narrowi

7、ng conversions 类型退化 type decay 范围错误 range errors void 类型指针 我们可以通过约束这些特性的使用 或者使用 C 的新特性 比如 variant C 17 GSL 的 span narrow cast 等来解决这些问题 提高 C 代码的健壮性 遵循遵循 C ISO 标准标准 希望通过使用 ISO C 标准的特性来编写 C 代码 对于 ISO 标准中未定义的或者 编译器实现的特性要谨慎使用 对于 GCC 等编译器的提供的扩展特性也需要谨慎 使用 这些特性会导致代码的可移植性比较差 注意 如果模块中需要使用相关的扩展特性来 那么尽可能将这些特性封装

8、成独立 的接口 并且可以通过编译选项关闭或者编译这些特性 对于这些扩展特性的使用 请模块制定特性编程指南来指导这些特性的使用 优先编译时检查错误优先编译时检查错误 通过编译器来优先保证代码健壮性 而不是通过编写错误处理代码来处理编译就可 以发现的异常 比如 通过 const 来保证数据的不变性 防止数据被无意修改 通过 gsl span 等来保证 char 数组不越界 而不是通过运行时的 length 检查 通过 static assert 来进行编译时检查 使用命名空间来限定作用域使用命名空间来限定作用域 全局变量 全局常量和全局类型定义由于都属于全局作用域 在项目中 使用第三 方库中容易出

9、现冲突 命名空间将作用域细分为独立的 具名的作用域 可有效地防止全局作用域的命名 冲突 1 class struct 等都具有自己的类作用域 2 具名的 namespace 可以实现 类作用域更上层的作用域 3 匿名 namespace 和 static 可以实现文件作用域 对于没有作用域的宏变量 宏函数强烈建议不使用 作用域的一些缺点 1 虽然可以通过作用域来区分两个命名相同的类型 但是还 是具有迷惑性 2 内联命名空间会让命名空间内部的成员摆脱限制 让人迷惑 3 通过多重嵌套来定义 namespace 会让完整的命名空间比较冗长 所以 我们使用命名空间的建议如下 对于变量 常量和类型定义尽

10、可能使用 namespace 减少全局作用域的冲突 不要在头文件中使用 using namespace 不要 使用内联命名空间 鼓励在 cpp 文件中通过匿名 namespace 或者 static 来封装 防止不必要的定义通过 API 暴露出去 优先使用优先使用 C 特性而不是特性而不是 C 特性特性 C 比起 C 语言更加类型安全 更加抽象 我们更推荐使用 C 的语言特性来编程 比如使用 string 而不是char 使用 vector 而不是原生数组 使用 namespace 而不 是 static 2 命名命名 通用命名通用命名 常见命名风格有 驼峰风格驼峰风格 CamelCase 大

11、小写字母混用 单词连在一起 不同 单词间通过单词首字母大写来分开 按连接后的首字母是否大写 又分 大驼峰 UperCamelCase 和小驼峰 lowerCamelCase 内核风格内核风格 unix like 单词全小写 用下划线分割 如 test result 匈牙利风格匈牙利风格 在 大驼峰 的基础上 加上前缀 前缀用于表达类型或用途 如 uiSavedCount bTested 规则规则 2 1 1 标识符命名使用驼峰风格标识符命名使用驼峰风格 不考虑匈牙利命名 在内核风格与驼峰风格之间 根据存量代码的情况 我们选择 驼峰风格 类型 命名风格 类类型 结构体类型 枚举类型 联合体类型等

12、类型定 义 大驼峰 函数 包括全局函数 作用域函数 成员函数 大驼峰 接口部分可加 前缀 如 XXX 函数 名 全局变量 包括全局和命名空间域下的变量 类静态变 量 局部变量 函数参数 类 结构体和联合体中的成 员变量 小驼峰 常量 const 枚举值 k 大小写混合 宏 大写 下划线 命名空间 全小写 注意 上表中 常量 是指全局作用域 namespace 域 类的静态成员域下 以 const 或 constexpr 修饰的基本数据类型 枚举 字符串类型的变量 上表中 变 量 是指除常量定义以外的其他变量 均使用小驼峰风格 文件命名文件命名 建议建议 2 2 1 C 文件以文件以 cpp 结

13、尾 头文件以结尾 头文件以 h 结尾结尾 我们推荐使用 h 作为头文件的后缀 这样头文件可以直接兼容 C 和 C 我们推 荐使用 cpp 作为实现文件的后缀 这样可以直接区分 C 代码 而不是 C 代码 目前业界还有一些其他的后缀的表示方法 头文件 hh hpp hxx cpp 文件 cc cxx C 对于本文档 我们默认使用 h 和 cpp 作为后缀 建议建议 2 2 2 C 文件名和类名保持一致文件名和类名保持一致 C 的头文件和 cpp 文件名和类名保持一致 使用下划线小写风格 如下 database connection h database connection cpp 结构体 命名

14、空间 枚举等定义的文件名类似 函数命名函数命名 函数命名统一使用大驼峰风格 一般采用动词或者动宾结构 接口部分可加前缀 如 XXX 函数名 class List public void AddElement const Element Element GetElement const unsigned int index const bool IsEmpty const bool MCC GetClass namespace utils void DeleteUser 类型命名类型命名 类型命名采用大驼峰命名风格 所有类型命名 类 结构体 联合体 类型定 义 typedef 枚举 使用相同约定

15、 例如 classes structs and unions class UrlTable class UrlTableTester struct UrlTableProperties union Packet typedefs typedef std map PropertiesMap enums enum UrlTableErrors 对于命名空间的命名 建议全小写 namespace namespace osutils namespace fileutils 建议建议 2 4 1 避免滥用避免滥用 typedef 或者或者 define 对基本类型起别名对基本类型起别名 除有明确的必要性

16、 否则不要用 typedef define 对基本数据类型进行重定义 优 先使用头文件中的基本类型 有符号类型 无符号类型 描述 int8 t uint8 t 宽度恰为 8 的有 无符号整数类型 int16 t uint16 t 宽度恰为 16 的有 无符号整数类型 int32 t uint32 t 宽度恰为 32 的有 无符号整数类型 int64 t uint64 t 宽度恰为 64 的有 无符号整数类型 intptr t uintptr t 足以保存指针的有 无符号整数类型 如果模块有自己的定义 请使用统一的 typedef 来定义类型 typedef signed char VOS INT8 typedef unsigned char VOS UINT8 if WORDSIZE 64 typedef unsigned long int VOS UINTPTR else typedef unsigned int VOS UINTPTR endif 如果模块为了封装某个类型的信息 方便后续的扩展 可以使用 typedef 来重新定 义 typedef uint8 t DeviceID

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 办公文档 > 规章制度

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号