每个C或C ++文件都应该有一个关联的头文件吗？
是否每个.C或.cpp文件都应该有一个标题（.h）文件？
假设有以下C文件：
-
MAIN.C
-
Func1.C
-
Func2.C
-
Func3.C
其中main()在Main.C文件中。 应该有四个头文件
-
Main.h
-
Func1.h
-
Func2.h
-
Func3.h
或者所有.C文件应该只有一个头文件？
什么是更好的方法？
有一个main.h是不寻常的，因为在编译时通常没有什么需要暴露给其他编译单元。 main()本身需要为链接器/启动代码公开，但它们不使用头文件。
每个C文件可以有一个头文件，或者很可能是相关C文件组的头文件。
其中一个例子是，如果你有一个BTree实现，并且你已经在他们自己的C文件中添加，删除，搜索等，以便在代码更改时最小化重新编译。
在这种情况下，每个C文件都有单独的头文件是没有意义的，因为头是API，即用户库的视图。 我怀疑用户是否希望包含6个头文件才能使用这些function。 将有一个btree.h文件和一个btree.lib文件，其中包含从各个C文件构建的所有BTree对象。
另一个例子可以在标准C头中找到。 我们不确定stdio.h函数是否有多个C文件（这就是我怎么做但它不是唯一的方法）但是，即使有，它们也被视为一个单元的术语的API。 您不必包含stdio_printf.h ， stdio_fgets.h等等 – 对于C运行时库的标准I / O部分，只有一个stdio.h 。
-
头文件不是必需的。
-
#include简单地复制/粘贴包含的任何文件（包括.c源文件） -
在现实生活项目中常用的是全局头文件，如
config.h和constants.h，它们包含常用信息，如编译时标志和项目范围常量。 -
一个好的库API设计就是用一组头文件公开官方接口，并使用一组内部头文件来实现所有细节。 这为C库增加了一个很好的额外抽象层，而不会增加不必要的膨胀。
-
使用常识。 C / C ++并不适合没有它的人。
我曾经遵循“依赖”的趋势，直到我意识到一致性，一致性和简单性比节省创建文件的努力更重要，并且“即使它们很糟糕，标准也很好”。
我的意思是以下内容：.cpp / .h对文件几乎就是所有“模块”最终的结果。 使两者都成为一项要求可以避免很多混乱和糟糕的工程设计。
例如，当我在头文件中看到某些东西的界面时，我确切地知道在哪里搜索/放置它的实现。 相反，如果我需要公开以前隐藏在.cpp文件中的某些东西的界面（例如静态函数变为全局），我就知道确切的位置。
我看到了不遵循这个简单规则的太多不良后果。 不必要的内联函数，破坏任何关于封装的规则，（非）分离接口和实现，错位的代码，仅举几例 – 所有这些都是由于从未添加适当的兄弟头或cpp文件这一事实。
所以：始终定义.h和.c文件。 使其成为标准，遵循它，并安全地依赖它。 生活这种方式简单得多，简洁是软件中最重要的事情。
通常，最好为每个.c文件都有一个头文件，其中包含要公开的.c文件中的函数声明等。 这样，另一个.c文件可以包含所需函数的.h文件，如果不包含的头文件被更改，则不需要重新编译.c文件。
通常，每个.c / .cpp文件都会有一个.h文件。
这取决于。 通常你有单独的.c文件的原因将决定你是否需要单独的.h文件。
我喜欢将接口放入头文件和cpp文件中的实现。 我不喜欢编写C ++，我需要在头文件中添加成员变量和原型，然后在C ++中再次添加方法。 我喜欢这样的东西：
module.h中
struct IModuleInterface : public IUnknown { virtual void SomeMethod () = 0; }
module.cpp
class ModuleImpl : public IModuleInterface, public CObject // a common object to do the reference // counting stuff for IUnknown (so we // can stick this object in a smart // pointer). { ModuleImpl () : m_MemberVariable (0) { } int m_MemberVariable; void SomeInternalMethod () { // some internal code that doesn't need to be in the interface } void SometMethod () { // implementation for the method in the interface } // whatever else we need };
我发现这是一种非常简洁的分离实现和界面的方式。
Bjarne Stroustrup在他的“C ++编程语言”一书中详细解释了它。
当程序很小并且其部分不打算单独使用时，单个标题样式的物理分区是最有用的。 使用名称空间时，程序的逻辑结构仍然可以在单个头文件中解释。
对于较大的程序，单个头文件方法在传统的基于文件的开发环境中是不可行的。 对公共头的更改会强制重新编译整个程序，并且几个程序员对该单个头的更新很容易出错。 除非强调严重依赖命名空间和类的编程风格，否则逻辑结构会随着程序的增长而恶化。
另一种物理组织允许每个逻辑模块都有自己的标头来定义它提供的设施。 然后每个.c文件都有一个相应的h。 文件指定它提供的内容（其接口）。 每个.c模块都包含自己的.h文件，通常还有其他.h文件，用于指定其他模块需要的内容，以实现其界面中公布的服务。 该物理组织对应于模块的逻辑组织。 多头方法可以轻松确定依赖关系。 单头方法迫使我们查看任何模块使用的每个声明，并决定它是否相关。 简单的事实是，代码的维护总是使用不完整的信息和从本地的角度来完成。 更好的本地化导致编译模块的信息更少，从而加快编译速度。
没有更好的方法，只有普通和不常见的情况。
更常见的情况是你有一个声明/定义的类/函数接口。 最好只有一个带有定义的.cpp / .c和一个用于声明的头文件。 给它们相同的名称很容易理解它们是直接相关的。
但这不是一个“规则”，这是几乎所有情况下的常用方法和最有效方法。
现在在某些情况下（比如模板类或一些微小的结构定义）你不需要任何.c / .cpp文件，只需要标题。 我们经常只在头文件中有一些虚拟类接口定义，例如，只有虚拟纯函数或普通函数。
在其他极少数情况下（如假设的main.c / .cpp文件），如果不总是需要允许外部编译单元的代码调用给定编译单元的函数。 主要function是一个示例（不需要标头/声明），但还有其他function，主要是当它的代码“将所有其他部分连接在一起”并且不被应用程序的其他部分调用时。 这是非常罕见的，但在这种情况下，标题是没有意义的。
关键是什么代码需要知道其他代码。 您希望将其他文件所知的数量减少到最低限度，以便他们完成工作。
他们需要知道一个函数存在，它们需要传递给它的类型，以及它将返回什么类型，但不知道它在内部做什么。 请注意，从程序员的角度来看，知道这些类型实际意味着什么也很重要。 （例如，哪个int是行，哪个是列）但代码本身并不关心。 这就是为什么明智地命名function和参数是值得的。
正如其他人所说，如果cpp文件中没有任何内容值得暴露给代码的其他部分，通常是main.c的情况，那么就不需要头文件了。
偶尔值得将你想要公开的所有东西放在一个头文件中（例如，Func1and2and3.h），这样任何了解Func1的东西都知道Func2，但我个人并不热衷于此，因为它意味着你倾向于加载大量垃圾和你真正想要的东西。
简介：想象一下，您相信某人可以编写代码并且他们的算法，设计等都是好的。 你想使用他们编写的代码。 所有你需要知道的是让他们得到一些事情，你应该给它什么，以及你会得到什么。 这是头文件中需要的东西。
如果您的文件公开了一个接口 – 也就是说，如果它具有将从其他文件调用的函数 – 那么它应该有一个头文件。 否则，它不应该。
如前所述，通常，每个源（.c或.cpp）文件都有一个标题（.h）文件。
但是，您应该看一下文件的内聚性。 如果各种源文件提供单独的，可单独重用的function集 – 一个理想的组织 – 那么每个文件当然应该有一个头。 但是，如果三个源文件提供了一组复合函数（太大而无法放入一个文件中），那么您将使用更复杂的组织。 主程序使用的外部服务将有一个标头 – 并且将由需要相同服务的其他程序使用。 合作源文件还将使用第二个标头，提供由这些文件共享的“内部”定义。
（也由Pax注意到）：主程序通常不需要自己的头 – 没有其他源代码应该使用它提供的服务; 它使用其他文件提供的服务。
如果您希望从另一个编译单元使用已编译的代码，则需要头文件。 在某些情况下，您现在需要/想要拥有标题。
第一个这样的情况是main.c / cpp文件。 这个类并不意味着包含在内，因此不需要头文件。
在某些情况下，您可以使用头文件来定义通过在运行时加载的dll加载的一组不同实现的行为。 将有不同的.c / .cpp文件集来实现相同标头的变体。 这在插件系统中很常见。
通常cpp / c文件用于实现，而h / hpp（经常不使用hpp）文件用于头文件（仅原型和声明）。 Cpp文件并不总是必须有一个与之关联的头文件，但它通常会这样做，因为头文件就像cpp文件之间的桥梁，因此每个cpp文件都可以使用另一个cpp文件中的代码。
应该强制执行的一件事是在头文件中不使用代码！ 由于重新定义，头文件在任何大小的项目中都会破坏编译的次数太多了。 这就是当您将头文件包含在2个不同的cpp文件中时。 头文件应始终设计为包含多次。 永远不应该包含Cpp文件。
一般来说，我认为.h和.c文件之间没有任何明确的关系。 在许多情况下（可能是大多数），代码单元是具有公共接口（.h）和不透明实现（.c）的function库。 有时需要一些符号，比如枚举或宏，并且你得到一个没有相应.c的.h，在少数情况下，你会有一堆代码，没有公共接口而没有相应的.h
特别是，出于可读性的考虑，为了程序员的理智，有时候为了便于阅读，标题或实现（很少两者）都如此庞大和毛茸茸，最终被分成许多较小的文件。