c++谷歌代码规范

此文是针对Google开源项目风格指南的笔记

风格 (style, 亦称作可读性 (readability)) 是用于管理 C++ 代码的惯例. “风格” 这一术语略有不准确, 因为这些惯例并非仅仅囊括代码格式.

  • 为读者优化, 而非为作者优化

  • 和现有代码保持一致

  • 避免使用奇特或危险的语法结构

  • 避免使用那些正常水平的 C++ 程序员认为棘手或难以维护的语法结构

  • 需要注意我们的规模

    举例来说, 一定要避免污染全局命名空间 (global namespace): 如果所有人都往全局命名空间里塞东西, 就很难避免上亿行代码之间的符号冲突 (name collision), 也难以修复冲突.

  • 在必要时为优化让路

目前代码的目标版本是 C++20

针对C++谷歌代码规范的vscode拓展cpplint

头文件相关

自给自足的头文件

通常每个 .cc/ .cpp 文件应该有一个配套的 .h 文件. 常见的例外情况包括单元测试和仅有 main() 函数的 .cc 文件.

头文件应该自给自足 (self-contained, 也就是可以独立编译), 并以 .h 为扩展名. 给需要被导入 (include) 但不属于头文件的文件设置为 .inc 扩展名, 并尽量避免使用.

在少数情况下,用于导入的文件可能不能独立存在,通常是需要在特定位置导入,例如在另一个文件的中间位置。这种文件不需要使用头文件防护符(ifndef guard),也不需要导入其依赖。这种文件应该使用 .inc 扩展名。建议尽量避免使用这种文件,如果可能的话应该使用独立的头文件。

头文件中的内联函数和模板

若头文件声明了内联函数 (inline function) 或模版 (template), 而且头文件的使用者需要实例化 (instantiate) 这些组件时:(三种处理方式)

  • 头文件中直接包含模板或内联函数定义
  • 头文件中间接导入一个单独的源文件(包含模板或内联函数的实现的源文件)
  • 若模版的所有实例化过程(使用)都仅出现在一个源文件中, 比如采用显式 (explicit) 实例化, 或者只有这个 .cc 文件会用到模版定义 (definition), 那么可以把模版的定义放在这个文件里.

#define防护符

所有头文件都应该用 #define 防护符来防止重复导入. 防护符的格式是: <项目>_<路径>_<文件名>_H_ .

例如, foo 项目中的文件 foo/src/bar/baz.h 应该有如下防护:

1
2
3
4
#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif // FOO_BAR_BAZ_H_

导入你的依赖