【问题标题】:Google C++ Style Guide include order谷歌 C++ 风格指南包括订单
【发布时间】:2019-01-24 13:29:41
【问题描述】:

Google C++ Style Guide 建议按以下顺序将头文件(.h)包含到实现文件(.cpp、.cc)中:

dir/foo.ccdir/foo_test.cc 中,其主要目的是实现或测试dir2/foo2.h 中的东西,按如下顺序排列您的include:

dir2/foo2.h.
A blank line
C system files.
C++ system files.
A blank line
Other libraries' .h files.
Your project's .h files.

如前所述,这样的顺序允许在编译foo-unit 时查看dir2/foo2.h 中省略的依赖项,而不是其他无辜单元。看起来很合乎逻辑。

但是为什么Other libraries' .h files.Your project's .h files. 放在列表末尾呢?理论上,也可能缺少依赖项,这些依赖项将通过在之前包含 C system files.C++ system files. 来隐藏。

也许假设应该在相关的实现文件中检测到其他(头)文件问题?在那种情况下,只有头文件的库呢?

换句话说,包含以下顺序:

dir2/foo2.h.
A blank line
Other libraries' .h files.
Your project's .h files.
A blank line
C system files.
C++ system files.

会更好更快地找到隐藏的依赖项吗?

例如,如果我只有需要 <stdio.h> 的标头(但未在该文件中指定)。使用 Google 命令直接或间接包含 <stdio.h> 的可能性高于在最后一步包含系统文件时(正如我之前建议的)。因此,找到隐藏依赖的概率很低。那么,如果在其他 lib/您的项目文件之前包含系统文件,我们将获得什么?

也不清楚,我是否应该在其他(用户定义的)头文件中使用推荐的包含文件顺序。

【问题讨论】:

  • 如果遵循相同的指导方针,在构建各自的源文件时应该会出现那些缺少的依赖项。
  • @Someprogrammerdude 请查看帖子更新。

标签: c++ include google-style-guide


【解决方案1】:

每个头文件(h,hpp,...)都应该有一个实现文件(cpp,cc,...),其中包含的顺序与问题中指定的顺序相同。 (即使实现文件是空的,除了这1个包含)

就像“Your”头文件首先包含在“Your”实现文件中一样,每个“other”头文件都应该首先包含在“other”实现文件中。

这样,如果“other”头文件不包含必需的头文件,“other”实现文件将无法编译。

【讨论】:

  • 那么......为什么在其他/您的.h文件之前包含系统文件的顺序比相反的要好?
  • 我没有看到任何论据为什么这比“相反”更好。 Google Style Guide 中的许多规则都是在没有任何理由的情况下编写的。关于首先包含“您的”头文件的规则是在过去几年中添加的。所以也许你的论点实际上更好。或者也许没关系?如果你的项目中的每个头文件都遵守这个规则,那么下一个头文件的顺序不重要吗?也许这只是一个规则,所以所有项目都是一致的。
  • Bloomberg Coding Standards 说:包含指令必须分为三组:(a) 与该组件在同一包中的组件 (b) 来自其他包的组件 (c) 其他必需的头文件组件(例如第三方或特定于平台的)。这会支持你的论点。
【解决方案2】:

要包含的 C 和 C++ 头文件是下面源代码使用的,它们不应包含其他库或项目头文件的依赖关系。

还有像模板这样的只有标题的模块:你确实为你的模块编写了一个测试程序,对吧?在测试程序中先包含模板头文件,然后您也可以在其中检测缺少的包含。

【讨论】:

    猜你喜欢
    • 2011-07-22
    • 2010-12-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-02-14
    • 2014-07-04
    • 1970-01-01
    • 2017-06-10
    相关资源
    最近更新 更多