包含分析
由于包含的巨大层次结构导致的长构建时间是大型实际 C++ 项目中最大的难题之一。 ReSharper 提供了一些功能，帮助您在设计时优化包含。 例如，它会 标记未使用的#include 指令，或者自动为未解析的名称创建前向声明，而不是包含具有所需声明的头文件。
为更系统地解决包含层次结构问题，ReSharper 提供了 包含分析器 ，这是一种代码检查工具，可帮助您定位并消除不必要的头文件依赖。
它如何有帮助？
一个典型的项目可能包含成千上万的 #include 指令，但不清楚其中哪些值得调查。 包含分析器尝试根据每个头文件对构建时间的贡献来估算其影响，基于它为总编译工作量增加的代码行数。 虽然这不是一个精确的指标，但它是一个有用的起点，用于查找和优先处理最常被包含的头文件。
在您识别出可能影响最大的头文件依赖后，您可以通过标准方法逐一尝试消除它们，例如：
包含分析器的一个重要限制是，ReSharper 实际上并未运行完整的预处理阶段，以加快分析过程。 这意味着行数实际上并未包括宏扩展的结果，并且包含保护也未被处理。 相反，ReSharper 假设每个头文件以包含保护或 #pragma once 指令开头，并且在任何源文件中最多只被包含一次。 同一头文件的每次后续包含不会计入其贡献的行数，这意味着有时您可能会在内部树节点旁边看到 包含次数 和其他指标为零。
开始分析
要开始分析，请从主菜单调用一个 操作，或从解决方案资源管理器上下文菜单中选择 分析 Include。
ReSharper 将分析给定范围内的文件，并在专用工具窗口中呈现报告，您可以在其中探索文件之间的依赖关系。 包含分析 窗口提供了两个独立的视图， 被包含者 和 包含者 ，这两个视图都以树的形式呈现包含依赖关系，其中每个节点对应一个文件。 您可以通过相应的工具栏按钮在这些视图之间切换，或者通过上下文菜单导航到另一个视图中的同一文件。
被包含视图
被包含者 视图帮助您了解顶级树节点中的头文件对所有直接或间接包含它的源文件贡献了多少代码行。 此视图中的子节点表示从父节点文件中包含的文件。 请考虑以下对整个 Catch2 解决方案的分析：
树中每个节点有三个指标：
包含次数 显示通过到当前节点的路径，顶级节点中的头文件被多少源文件包含。 在上面的示例中， catch_common.h 总共被 75 个源文件包含，其中 26 个通过 catch_common.h 中的
#include "catch_common.h"指令包含了 catch_tag_alias_autoregistrar.h 。行贡献 显示顶级节点中的头文件通过到当前节点的路径自身贡献了多少代码行，不包括传递性包含的文件。 catch_common.h 总共贡献了 4,050 行代码，这相当于 75（包含它的源文件数）乘以 54（文件中的代码行数）。 在总共 4,050 行中，有 1,404 行是由于
#include "catch_common.h"中的 catch_tag_alias_autoregistrar.h 贡献的。包含行贡献 类似于 行贡献 ，但此指标考虑了顶级节点文件中传递性包含的所有头文件。 例如， catch_common.h 连同其中包含的头文件，在整个解决方案的编译过程中总共贡献了 2,654,938 行。 其中有 1,017,626 行是由于
#include "catch_common.h"中的catch_tag_alias_autoregistrar.h贡献的。 包含行贡献 是默认且可以说是最有用的排序标准。
包含者视图
包含者 视图类似于 被包含者 视图，但作用相反：树中的子节点表示从父节点文件中包含的文件。
此视图显示在顶级节点中作为独立源文件编译时，文件中传递性包含的代码行数（例如， catch_common.h 连同其中包含的所有头文件，共计 42,365 行代码，其中 27,046 行是通过 #include<string>) 引入的）。 此视图提供的指标包括
被包含文件数 （包含的文件数量），
行数 （文件本身的大小），
包含行数 （文件及其包含的所有头文件的大小）。
选项
除了导航控件和刷新按钮外，包含分析窗口中的工具栏还允许您更改两个选项：
仅显示属于某些项目的根节点 将隐藏不属于任何项目的文件对应的顶级树节点。 如果您想专注于解决方案中的头文件，这是快速过滤掉库文件的方法。
默认情况下，ReSharper 在分析过程中会跳过空行和注释。 计算空行和注释行 按钮可让您更改此行为。