OpenHarmony鸿蒙OSC编程规范
⽂章⽬录
⽬的
总体原则
约定
例外
1 命名
总体风格
规则1.1 标识符命名使⽤驼峰风格
建议1.1 作⽤域越⼤，命名应越精确
⽂件命名
建议1.2 ⽂件命名统⼀采⽤⼩写字符
函数命名
建议1.3 函数的命名遵循阅读习惯
变量命名
规则1.2 全局变量应增加 'g_' 前缀，函数内静态变量命名不需要加特殊前缀
建议1.4 局部变量应该简短，且能够表达相关含义
类型命名
宏、常量、枚举命名
建议1.5 避免函数式宏中的临时变量命名污染外部作⽤域
2 排版格式
⾏宽
建议2.1 ⾏宽不超过 120 个字符
缩进
规则2.1 使⽤空格进⾏缩进，每次缩进4个空格
⼤括号
规则2.2 使⽤ K&R 缩进风格
函数声明和定义
规则2.3 函数声明、定义的返回类型和函数名在同⼀⾏；函数参数列表换⾏时应合理对齐函数调⽤
规则2.4 函数调⽤参数列表换⾏时保持参数进⾏合理对齐
条件语句
规则2.5 条件语句必须要使⽤⼤括号
规则2.6 禁⽌ if/else/else if 写在同⼀⾏
循环
规则2.7 循环语句必须使⽤⼤括号
switch语句
规则2.8 switch 语句的 case/default 要缩进⼀层
表达式
建议2.2 表达式换⾏要保持换⾏的⼀致性，操作符放⾏末
变量赋值
规则2.9 多个变量定义和赋值语句不允许写在⼀⾏
初始化
规则2.10 初始化换⾏时要有缩进，或进⾏合理对齐
规则2.11 结构体和联合体在按成员初始化时，每个成员初始化单独⼀⾏指针
建议2.3 指针类型"\*"跟随变量名或者类型，不要两边都留有空格或都没有空格编译预处理
规则2.12 编译预处理的"#"默认放在⾏⾸，嵌套编译预处理语句时，"#"可以进⾏缩进空格和空⾏
规则2.13 ⽔平空格应该突出关键字和重要信息，避免不必要的留⽩
建议2.4 合理安排空⾏，保持代码紧凑
3 注释
注释风格
⽂件头注释
规则3.1 ⽂件头注释必须包含版权许可
函数头注释
规则3.2 禁⽌空有格式的函数头注释
代码注释
规则3.3 代码注释放于对应代码的上⽅或右边
规则3.4 注释符与注释内容间要有1空格；右置注释与前⾯代码⾄少1空格
规则3.5 不⽤的代码段直接删除，不要注释掉
建议3.1 case语句块结束时如果不加break/return，需要有注释说明(fall-through) 4 头⽂件
头⽂件职责
建议4.1 每⼀个.c⽂件都应该有相应的.h⽂件，⽤于声明需要对外公开的接⼝
建议4.2 头⽂件的扩展名只使⽤.h，不使⽤⾮习惯⽤法的扩展名，如.inc 头⽂件依赖
规则4.1 禁⽌头⽂件循环依赖
规则4.2 头⽂件必须编写#define保护，防⽌重复包含
规则4.3 禁⽌通过声明的⽅式引⽤外部函数接⼝、变量
规则4.4 禁⽌在 extern "C" 中包含头⽂件
5 函数
函数设计
规则5.1 避免函数过长，函数不超过50⾏（⾮空⾮注释）
规则5.2 避免函数的代码块嵌套过深，不要超过4层
建议5.1 对函数的错误返回码要全⾯处理
函数参数
建议5.2 设计函数时，优先使⽤返回值⽽不是输出参数
建议5.3 使⽤强类型参数，避免使⽤void\*
建议5.4 模块内部函数参数的合法性检查，由调⽤者负责
建议5.5 函数的指针参数如果不是⽤于修改所指向的对象就应该声明为指向const的指针
建议5.6 函数的参数个数不超过5个
内联函数
建议5.7 内联函数不超过10⾏（⾮空⾮注释）
规则5.3 被多个源⽂件调⽤的内联函数要放在头⽂件中定义
6 宏
函数式宏(function-like macro)
建议6.1 使⽤函数代替函数式宏
规则6.1 定义宏时，宏参数要使⽤完备的括号
规则6.2 包含多条语句的函数式宏的实现语句必须放在 do-while(0) 中
规则6.3 不允许把带副作⽤的表达式作为参数传递给函数式宏
建议6.2 函数式宏定义中慎⽤ return、goto、continue、break 等改变程序流程的语句
建议6.3 函数式宏不超过10⾏(⾮空⾮注释)
7 变量
全局变量
规则7.1 模块间，禁⽌使⽤全局变量作接⼝
局部变量
规则7.2 严禁使⽤未经初始化的变量
规则7.3 禁⽌⽆效、冗余的变量初始化
规则7.4 不允许使⽤魔⿁数字
8 编程实践
表达式
建议8.1 表达式的⽐较，应当遵循左侧倾向于变化、右侧倾向于不变的原则
规则8.1 含有变量⾃增或⾃减运算的表达式中禁⽌再次引⽤该变量
建议8.2 ⽤括号明确表达式的操作顺序，避免过分依赖默认优先级
语句
规则8.2 switch语句要有default分⽀
建议8.3 慎⽤ goto 语句
类型转换
建议8.4 尽量减少没有必要的数据类型默认转换与强制转换
C语⾔编程规范
⽬的
规则并不是完美的，通过禁⽌在特定情况下有⽤的特性，可能会对代码实现造成影响。但是我们制定规则的⽬的“为了⼤多数程序员可以得到更多的好处”， 如果在团队运作中认为某个规则⽆法遵循，希望可以共同改进该规则。
参考该规范之前，希望您具有相应的C语⾔基础能⼒，⽽不是通过该⽂档来学习C语⾔。
1. 了解C语⾔的ISO标准；
2. 熟知C语⾔的基本语⾔特性；
3. 了解C语⾔的标准库；
总体原则
代码需要在保证功能正确的前提下，满⾜可读、可维护、安全、可靠、可测试、⾼效、可移植的特征要求。
约定
switch函数用法举例规则：编程时必须遵守的约定
建议：编程时必须加以考虑的约定
⽆论是“规则”还是“建议”，都必须理解该条⽬这么规定的原因，并努⼒遵守。
例外
在不违背总体原则，经过充分考虑，有充⾜的理由的前提下，可以适当违背规范中约定。
例外破坏了代码的⼀致性，请尽量避免。“规则”的例外应该是极少的。
下列情况，应风格⼀致性原则优先：
修改外部开源代码、第三⽅代码时，应该遵守开源代码、第三⽅代码已有规范，保持风格统⼀。
1 命名
命名包括⽂件、函数、变量、类型、宏等命名。
命名被认为是软件开发过程中最困难，也是最重要的事情。
标识符的命名要清晰、明了，有明确含义，符合阅读习惯，容易理解。
统⼀的命名风格是⼀致性原则最直接的体现。
总体风格
驼峰风格(CamelCase)
⼤⼩写字母混⽤，单词连在⼀起，不同单词间通过单词⾸字母⼤写来分开。
按连接后的⾸字母是否⼤写，⼜分: ⼤驼峰(UpperCamelCase)和⼩驼峰(lowerCamelCase)
规则1.1 标识符命名使⽤驼峰风格
类型命名风格
函数，结构体类型，枚举类型，联合体类型⼤驼峰变量，函数参数，宏参数，结构体中字段，联合体中成员⼩驼峰
宏，常量，枚举值，goto 标签全⼤写，下划线分割
注意：
上表中常量是指，全局作⽤域下，const 修饰的基本数据类型、枚举、字符串类型的变量，不包括数组、结构体和联合体。
上表中变量是指除常量定义以外的其他变量，均使⽤⼩驼峰风格。
建议1.1 作⽤域越⼤，命名应越精确
C 与 C++ 不同，没有名字空间，没有类，所以全局作⽤域下的标识符命名要考虑不要冲突。
对于全局函数、全局变量、宏、类型名、枚举名的命名，应当精确描述并全局唯⼀。
例：
int GetCount(void);// Bad: 描述不精确
int GetActiveConnectCount(void);// Good
为了命名更精确，必要时可以增加模块前缀。
模块前缀与命名主体之间，按驼峰⽅式连接。
⽰例：
int PrefixFuncName(void);// OK: 驼峰⽅式，形式上⽆前缀，内容上有前缀
enum XxxMyEnum {// OK.
...
};
⽂件命名
建议1.2 ⽂件命名统⼀采⽤⼩写字符
⽂件名命名只允许使⽤⼩写字母、数字以及下划线(_)。
⽂件名应尽量简短、准确、⽆⼆义性。
不⼤⼩写混⽤的原因是，不同系统对⽂件名⼤⼩写处理会不同（如 MicroSoft 的 DOS, Windows 系统不区分⼤⼩写，但是 Unix / Linux, Mac 系统则默认区分）。
好的命名举例：
dhcp_user_log.c
坏的命名举例：
dhcp_user-log.c: 不推荐⽤’-'分隔
dhcpuserlog.c: 未分割单词，可读性差
函数命名
函数命名统⼀使⽤⼤驼峰风格。
建议1.3 函数的命名遵循阅读习惯
动作类函数名，可以使⽤动宾结构。如：
AddTableEntry()// OK
DeleteUser()// OK
GetUserInfo()// OK
判断型函数，可以⽤形容词，或加 is：
DataReady()// OK
IsRunning()// OK
JobDone()// OK
数据型函数：
TotalCount()// OK
GetTotalCount()// OK
变量命名
变量命名使⽤⼩驼峰风格，包括全局变量，局部变量，函数声明或定义中的参数，带括号宏中的参数。
规则1.2 全局变量应增加 ‘g_’ 前缀，函数内静态变量命名不需要加特殊前缀
全局变量应当尽量少使⽤，使⽤时应特别注意，所以加上前缀⽤于视觉上的突出，促使开发⼈员对这些变量的使⽤更加⼩⼼。
全局静态变量命名与全局变量相同，函数内的静态变量命名与普通局部变量相同。

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