未验证 提交 5a2c190c 编写于 作者: O openharmony_ci 提交者: Gitee

!4958 优化OpenHarmony-cpp-coding-style-guide.md

Merge pull request !4958 from Tianshi Liu/master
...@@ -516,14 +516,14 @@ int&p = i; // Bad ...@@ -516,14 +516,14 @@ int&p = i; // Bad
在文件头保护宏、条件编译、日志记录等必要场景中可以使用宏。 在文件头保护宏、条件编译、日志记录等必要场景中可以使用宏。
### <a name="r3-13-3"></a>规则3.13.3 禁止使用宏来表示常量 ### <a name="r3-13-3"></a>规则3.13.3 禁止使用宏来表示常量
宏是简单的文本替换,在预处理阶段完成,运行报错时直接报相应的值;跟踪调试时也是显示值,而不是宏名; 宏没有类型检查,不全; 宏没有作用域。 宏是简单的文本替换,在预处理阶段完成,运行报错时直接报相应的值;跟踪调试时也是显示值,而不是宏名; 宏没有类型检查,不全; 宏没有作用域。
### <a name="r3-13-4"></a>规则3.13.4 禁止使用函数式宏 ### <a name="r3-13-4"></a>规则3.13.4 禁止使用函数式宏
宏义函数式宏前,应考虑能否用函数替代。对于可替代场景,建议用函数替代宏。 宏义函数式宏前,应考虑能否用函数替代。对于可替代场景,建议用函数替代宏。
函数式宏的缺点如下: 函数式宏的缺点如下:
- 函数式宏缺乏类型检查,不如函数调用检查严格 - 函数式宏缺乏类型检查,不如函数调用检查严格
- 宏展开时宏参数不求值,可能会产生非预期结果 - 宏展开时宏参数不求值,可能会产生非预期结果
- 宏没有独产的作用域 - 宏没有独立的作用域
- 宏的技巧性太强,例如#的用法和无处不在的括号,影响可读性 - 宏的技巧性太强,例如#的用法和无处不在的括号,影响可读性
- 在特定场景中必须用编译器对宏的扩展语法,如GCC的statement expression,影响可移植性 - 在特定场景中必须用编译器对宏的扩展语法,如GCC的statement expression,影响可移植性
- 宏在预编译阶段展开后,在期后编译、链接和调试时都不可见;而且包含多行的宏会展开为一行。函数式宏难以调试、难以打断点,不利于定位问题 - 宏在预编译阶段展开后,在期后编译、链接和调试时都不可见;而且包含多行的宏会展开为一行。函数式宏难以调试、难以打断点,不利于定位问题
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册