首先，我知道如何将C文件拆分成多个文件。
我的问题是，除了可读性之外，还有什么优势吗？拆分C文件的主要原因是什么？
答案 0 :(得分：2)
如果您将一个大型C文件拆分为几个翻译单元，您实际上必须在一些常见的包含标题中声明所涉及的函数（例如extern）。
拆分的好处是增量构建时间可能会略微缩小。如果在一个函数中只更改一个语句，则只需要编译定义该函数的文件（如果该文件很小，则编译速度很快）。但是，编译器需要解析所有标头。您可能希望在头文件中定义static inline函数（这会使它们更大）。
拆分的缺点是开发人员可能更难找到给定的函数（但是像ctags这样的工具帮助）并且编译器可能可以更少地优化（例如，赢得内联的一些函数调用） ，除非您启用链接时间优化）
所以这是品味和习惯的问题。就个人而言，我喜欢拥有超过一千行（可能少于一万行）的C或C ++文件，但是YMMV。而且我不喜欢每个文件有一个函数（少于一百行）的项目（在这种情况下你需要很多它们）。但是拥有一个十万行的大型源文件通常是不合理的。
我还发现源文件使相关函数更易读（因为在一个文件中搜索函数定义比在多个文件中搜索更简单）。
请注意，头文件可能会扩展到非常大的东西（在现代C ++中更是如此：像<vector>或<map>这样的标准头可能扩展到超过一万行代码） ，例如<stdio.h>扩展到两千行（在我的Debian / Linux / x86-64上），因此拥有大量小的源文件会减慢完整的构建时间（因为编译器确实看到了预处理的形式，在扩展#include指令后。）
使用GCC，您可能希望拥有一个标题（包括其他标题）和pre-compile。
BTW，将一个大文件拆分成几个较小的文件，或合并几个小文件并不是什么大问题。所以我认为这不是很重要。在某些情况下（在小型微控制器上嵌入式C程序，Arduino之类），二进制程序大小非常重要，这可能是拥有许多目标文件（如此多的C源文件）的原因，因为您和＃39; ll只链接真正需要的那些。
答案 1 :(得分：1)
如果要将函数放在可能由许多不同程序使用的库中，则将每个函数放在单独的文件中具有明显的优势。
假设库包含500个函数，而program1仅引用其中的2个，而program2引用其中的150个。然后只有2个函数将被加载到第一个可执行文件中，只有150个将加载到第二个函数中。
如果所有函数都包含在一个文件中，那么所有500个函数都将被加载到每个程序中，使它们非常大并且包含从未使用过的代码。