我今天想知道人们在决定将其拆分为多个较小的文件之前，通常在单个源文件中有多少代码。
就我个人而言，我倾向于保持我的文件相当小（特别是使用 C/C++ 时的头文件）。也就是说，我通常在给定文件中只有一个类或一堆函数，因此文件通常 <500 行。然而，所有相关的东西通常共享相同的命名空间。
另一方面，我使用的一些东西似乎很乐意尝试尽可能多地粘贴到单个文件中，该文件有 1000 行长。
我更喜欢小文件，因为任何更改只需要重新编译那一段代码，而且我发现将源代码分解为每个具有特定目的的较小文件时更容易导航源代码，而不是一个关于整个事物的大文件。几个大文件有什么真正的优势吗？
例如，我的粒子系统被分解为 system.h、emitter.h、load.h、particle.h 等，并且每个都有对应的 .cpp 文件。然而，我查看的一些粒子系统似乎已将整个源放入单个 .h 和 .cpp 1000 行长的行中。
毫无疑问，较小的文件更容易阅读和理解。但是，我认为您不能根据类或源文件中的行数做出此决定。如果您认为应该将通用功能放在不同的文件中，请考虑拆分您的代码。它还将允许更好地重用代码。
您应该从逻辑上而非物理上识别软件模块。因此，您应该根据职责设计类/功能。
您可以使用 CRC 方法来识别每个类的责任。
这当然取决于，你不能把自己限制在一个标准上。但我在一篇文章中读到
你的方法应该是一个屏幕宽的，所以你可以在不滚动的情况下看到它发生了什么，
您的方法参数应该小于或等于 7，并且您的继承深度应该小于或等于 3，这对于人类来说很容易理解。
在我看来，文件的限制应该是它的责任。每个文件都应该需要它自己的类，并且每个类都应该有一个责任。
每个源文件中的太少与拥有太多一样糟糕 - 混乱只会从单个源文件中转移到项目本身。
当我注意到一个源文件开始处理两个（或更多）明显独立的方面时，我倾向于将其拆分。
如果我感觉它包含将来可能会进行大量修改的功能，同时也具有可能稳定的功能，我也会将其拆分。
如果您不希望代码更改，那么巨大的单个文件对用户来说可能更方便。例如，SQLite 将他们的代码作为一个单一的源文件分发，用户可以轻松地将其合并到他们自己的构建中。
然而，在开发过程中，这是一个糟糕的想法，因为你提到的原因，也因为它几乎可以保证当多个程序员在项目上工作时会出现 RCS 合并问题。
我将项目的所有不同部分拆分为不同的文件，主要是为了与它相关的编译时间。当我需要链接的 CC 文件的对象已经存在时，我不必从头开始重新编译这些对象。
在整体文件和或更小的文件之间做出决定应该是团队的决定，并且应该在团队中每个程序员都遵循的编码规则中加以规定，就像有关于使用的制表符/空格的指南一样，应该有关于如何添加新代码的指南到项目。
对于某些项目，将尽可能多的代码放在一起更有意义，特别是如果只使用项目的一个部分而没有其余部分会使整个事情实际上毫无用处。这是一个权衡，你必须权衡利弊，最终你必须决定哪一个更适合你。
话虽如此，许多较小的文件允许多个开发人员使用类似于 Perforce 的版本控制系统进行更轻松的开发，因为它使一个开发人员所做的更改不太可能导致另一个开发人员处理另一段代码时需要解决的提交问题。