OpenHarmony鸿蒙OSC++编程规范
⽂章⽬录
⽬的
总体原则
重点关注
约定
例外
2 命名
通⽤命名
⽂件命名
建议2.2.1 C++⽂件以.cpp结尾，头⽂件以.h结尾
建议2.2.2 C++⽂件名和类名保持⼀致
函数命名
类型命名
建议2.4.1 避免滥⽤ typedef或者#define 对基本类型起别名
变量命名
规则2.5.1 全局变量应增加 'g_' 前缀，静态变量命名不需要加特殊前缀
规则2.5.2 类的成员变量命名以⼩驼峰加后下划线组成
switch函数用法举例
宏、常量、枚举命名
3 格式
⾏宽
建议3.1.1 ⾏宽不超过 120 个字符
缩进
规则3.2.1 使⽤空格进⾏缩进，每次缩进4个空格
⼤括号
规则3.3.1 使⽤ K&R 缩进风格
函数声明和定义
规则3.4.1 函数声明和定义的返回类型和函数名在同⼀⾏；函数参数列表超出⾏宽时要换⾏并合理对齐函数调⽤
规则3.5.1 函数调⽤⼊参列表应放在⼀⾏，超出⾏宽换⾏时，保持参数进⾏合理对齐if语句
规则3.6.1 if语句必须要使⽤⼤括号
规则3.6.2 禁⽌ if/else/else if 写在同⼀⾏
循环语句
规则3.7.1 循环语句必须使⽤⼤括号
switch语句
规则3.8.1 switch 语句的 case/default 要缩进⼀层
表达式
建议3.9.1 表达式换⾏要保持换⾏的⼀致性，运算符放⾏末
变量赋值
规则3.10.1 多个变量定义和赋值语句不允许写在⼀⾏
初始化
规则3.11.1 初始化换⾏时要有缩进，并进⾏合理对齐
指针与引⽤
建议3.12.1 指针类型"`*`"跟随变量名或者类型，不要两边都留有或者都没有空格
建议3.12.2 引⽤类型"`&`"跟随变量名或者类型，不要两边都留有或者都没有空格
编译预处理
规则3.13.1 编译预处理的"#"统⼀放在⾏⾸，嵌套编译预处理语句时，"#"可以进⾏缩进空格和空⾏
规则3.14.1 ⽔平空格应该突出关键字和重要信息，避免不必要的留⽩
建议3.14.1 合理安排空⾏，保持代码紧凑
类
规则3.15.1 类访问控制块的声明依次序是 public:, protected:, private:，缩进和 class 关键字对齐
规则3.15.2 构造函数初始化列表放在同⼀⾏或按四格缩进并排多⾏
4 注释
注释风格
⽂件头注释
规则3.1 ⽂件头注释必须包含版权许可
函数头注释
规则4.3.1 禁⽌空有格式的函数头注释
代码注释
规则4.4.1 代码注释放于对应代码的上⽅或右边
规则4.4.2 注释符与注释内容间要有1空格；右置注释与前⾯代码⾄少1空格
规则4.4.3 不⽤的代码段直接删除，不要注释掉
5 头⽂件
头⽂件职责
建议5.1.1 每⼀个.cpp⽂件应有⼀个对应的.h⽂件，⽤于声明需要对外公开的类与接⼝头⽂件依赖
规则5.2.1 禁⽌头⽂件循环依赖
规则5.2.2 头⽂件必须编写`#define`保护，防⽌重复包含
规则5.2.3 禁⽌通过声明的⽅式引⽤外部函数接⼝、变量
规则5.2.4 禁⽌在extern "C"中包含头⽂件
建议5.2.1尽量避免使⽤前置声明，⽽是通过`#include`来包含头⽂件
6 作⽤域
命名空间
建议6.1.1 对于cpp⽂件中不需要导出的变量，常量或者函数，请使⽤匿名namespace封装或者⽤static修饰
规则6.1.1 不要在头⽂件中或者#include之前使⽤using导⼊命名空间
全局函数和静态成员函数
建议6.2.1 优先使⽤命名空间来管理全局函数，如果和某个class有直接关系的，可以使⽤静态成员函数全局常量和静态成员常量
建议6.3.1 优先使⽤命名空间来管理全局常量，如果和某个class有直接关系的，可以使⽤静态成员常
量全局变量
建议6.4.1 尽量避免使⽤全局变量，考虑使⽤单例模式
7 类
构造，拷贝构造，赋值和析构函数
规则7.1.1 类的成员变量必须显式初始化
建议7.1.1 成员变量优先使⽤声明时初始化（C++11）和构造函数初始化列表初始化
规则7.1.2 为避免隐式转换，将单参数构造函数声明为explicit
规则7.1.3 如果不需要拷贝构造函数、赋值操作符 / 移动构造函数、赋值操作符，请明确禁⽌
规则7.1.4 拷贝构造和拷贝赋值操作符应该是成对出现或者禁⽌
规则7.1.5 移动构造和移动赋值操作符应该是成对出现或者禁⽌
规则7.1.6 禁⽌在构造函数和析构函数中调⽤虚函数
继承
规则7.2.1 基类的析构函数应该声明为virtual
规则7.2.2 禁⽌虚函数使⽤缺省参数值
规则7.2.3 禁⽌重新定义继承⽽来的⾮虚函数
多重继承
建议7.3.1 使⽤多重继承来实现接⼝分离与多⾓⾊组合
重载
8 函数
函数设计
规则8.1.1 避免函数过长，函数不超过50⾏（⾮空⾮注释）
内联函数
建议8.2.1 内联函数不超过10⾏（⾮空⾮注释）
函数参数
建议8.3.1 函数参数使⽤引⽤取代指针
建议8.3.2 使⽤强类型参数，避免使⽤void*
建议8.3.3 函数的参数个数不超过5个
9 C++其他特性
常量与初始化
规则9.1.1 不允许使⽤宏来表⽰常量
建议9.1.1 ⼀组相关的整型常量应定义为枚举
规则9.1.2 不允许使⽤魔⿁数字
规则9.1.3 常量应该保证单⼀职责
规则9.1.4 禁⽌⽤memcpy_s、memset_s初始化⾮POD对象
建议9.1.2 变量使⽤时才声明并初始化
表达式
规则9.2.1 含有变量⾃增或⾃减运算的表达式中禁⽌再次引⽤该变量
规则9.2.2 switch语句要有default分⽀
建议9.2.1 表达式的⽐较，应当遵循左侧倾向于变化、右侧倾向于不变的原则
建议9.2.2 使⽤括号明确操作符的优先级
类型转换
规则9.3.1 如果确定要使⽤类型转换，请使⽤由C++提供的类型转换，⽽不是C风格的类型转换
建议9.3.1 避免使⽤`dynamic_cast`
建议9.3.2 避免使⽤`reinterpret_cast`
建议9.3.3 避免使⽤`const_cast`
资源分配和释放
规则9.4.1 单个对象释放使⽤delete，数组对象释放使⽤delete []
建议9.4.1 使⽤ RAII 特性来帮助追踪动态分配
标准库
规则9.5.1 不要保存std::string的c_str()返回的指针
建议9.5.1 使⽤std::string代替char*
规则9.5.2 禁⽌使⽤auto_ptr
建议9.5.2 使⽤新的标准头⽂件
const的⽤法
规则9.6.1 对于指针和引⽤类型的形参，如果是不需要修改的，请使⽤const
规则9.6.2 对于不会修改成员变量的成员函数请使⽤const修饰
建议9.6.1 初始化后不会再修改的成员变量定义为const
异常
建议9.7.1 C++11中，如果函数不会抛出异常，声明为`noexcept`
模板
宏
10 现代C++特性
代码简洁性和安全性提升
建议10.1.1 合理使⽤`auto`
规则10.1.1 在重写虚函数时请使⽤`override`或`final`关键字
规则10.1.2 使⽤`delete`关键字删除函数
规则10.1.3 使⽤`nullptr`，⽽不是`NULL`或`0`
规则10.1.4 使⽤`using`⽽⾮`typedef`
规则10.1.5 禁⽌使⽤std::move操作const对象
智能指针
规则10.2.1 优先使⽤智能指针⽽不是原始指针管理资源
规则10.2.2 优先使⽤`unique_ptr`⽽不是`shared_ptr`
规则10.2.3 使⽤`std::make_unique`⽽不是`new`创建`unique_ptr`
规则10.2.4 使⽤`std::make_shared`⽽不是`new`创建`shared_ptr`
Lambda
建议10.3.1 当函数不能⼯作时选择使⽤`lambda`(捕获局部变量，或编写局部函数)
规则10.3.1 ⾮局部范围使⽤`lambdas`，避免使⽤按引⽤捕获
建议10.3.2 如果捕获`this`，则显式捕获所有变量
建议10.3.3 避免使⽤默认捕获模式
接⼝
建议10.4.1 不涉及所有权的场景，使⽤`T*`或`T&`作为参数，⽽不是智能指针
建议10.4.1 不涉及所有权的场景，使⽤`T*`或`T&`作为参数，⽽不是智能指针
C++语⾔编程规范
⽬的
规则并不是完美的，通过禁⽌在特定情况下有⽤的特性，可能会对代码实现造成影响。但是我们制定规则的⽬的“为了⼤多数程序员可以得到更多的好处”， 如果在团队运作中认为某个规则⽆法遵循，希望可以共同改进该规则。
参考该规范之前，希望您具有相应的C++语⾔基础能⼒，⽽不是通过该⽂档来学习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++标准, 如果没有特定的标准版本，适⽤所有的版本(C++03/11/14/17)。
例外
⽆论是’规则’还是’建议’，都必须理解该条⽬这么规定的原因，并努⼒遵守。
但是，有些规则和建议可能会有例外。
在不违背总体原则，经过充分考虑，有充⾜的理由的前提下，可以适当违背规范中约定。
例外破坏了代码的⼀致性，请尽量避免。'规则’的例外应该是极少的。
下列情况，应风格⼀致性原则优先：
修改外部开源代码、第三⽅代码时，应该遵守开源代码、第三⽅代码已有规范，保持风格统⼀。
2 命名
通⽤命名
驼峰风格(CamelCase)
⼤⼩写字母混⽤，单词连在⼀起，不同单词间通过单词⾸字母⼤写来分开。
按连接后的⾸字母是否⼤写，⼜分: ⼤驼峰(UpperCamelCase)和⼩驼峰(lowerCamelCase)
类型命名风格类类型，结构体类型，枚举类型，联合体类型等类型定义， 作⽤域名称⼤驼峰
函数(包括全局函数，作⽤域函数，成员函数)⼤驼峰全局变量(包括全局和命名空间域下的变量，类静态变量)，局部变量，函数参数，类、结构体和联合体中的成员变量⼩驼峰

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。