在单个文件中有多少代码是多少？

Question

我在想今天人们通常在单个源文件中有多少代码，然后才决定将其分割成多个较小的文件。

就我个人而言，我倾向于保持我的文件相当小（使用C/C++时，特别是头文件）。这是我通常只会有一个类或一个给定的文件中的一堆功能，所以该文件一般是500行。然而，所有相关的东西通常共享相同的命名空间。

另一方面，我所使用的一些东西似乎非常高兴地试图尽可能地将其保存到单个文件中，这个文件长度为1000年。

我更喜欢小文件，因为任何更改只需要重新编译一段代码，并且我发现当它被分解为每个具有特定用途的较小文件时更容易导航源代码，而不是一个大型文件整个事情。几个大文件有没有真正的优势？

例如我的粒子系统分解成system.h，emitter.h，load.h，particle.h等，并且对每个文件都有相应的.cpp文件。然而，一些粒子系统看起来似乎已将整个信号源整合到单个.h和.cpp 1000行的长度中。

Answer 1

小文件毫无疑问更容易阅读和理解。但是，我不认为你可以根据类或源文件中的行数来做出这个决定。如果您觉得应该将常用功能放在不同的文件中，请考虑分割您的代码。它还可以更好地重用代码。

Answer 2

您应该从逻辑上不物理地识别软件模块。 所以你应该根据责任来设计类/功能。

您可以使用CRC方法来确定每个班级的责任。

Answer 3

如果您不希望更改代码，那么对于用户而言，一个巨大的单个文件可能会更方便。例如，SQLite将它们的代码作为单片源文件分发，用户可以轻松地将它们合并到自己的版本中。

然而，在开发过程中，这是一个可怕的想法，因为你提到的原因，也因为它几乎可以保证当多个程序员在项目中工作时会出现RCS合并问题。

Answer 4

我将项目的所有不同部分分成不同的文件，主要用于与其相关的编译时间。当我需要链接的CC文件的对象已经存在时，我不必从头开始重新编译这些文件。

在单一文件或更小的文件之间做出决定应该是一个团队决策，应该在团队中的每个程序员都遵循的编码规则中阐明，就像使用标签/空间的准则一样，应该有如何准则向项目添加新的代码。

对于某些项目，将更多的代码放在一起更合理，特别是如果仅使用项目的一个单独部分而没有其余部分使得整个项目实际上无用。这是一个权衡，你必须衡量亲和骗局，并最终你必须决定哪一个会更好地为你工作。这就是说，许多较小的文件允许多个开发人员使用版本控制系统进行更简单的开发，就像Perforce一样，因为它会进行更改，一个开发人员不太可能导致另一个开发人员在另一个开发人员工作时需要解决的提交问题的代码。

Answer 5

这取决于当然，你不能限制自己的标准。但是，我在文章阅读

你的方法应该是屏幕宽，所以你可以看到它发生了什么不滚动，

参数到方法应小于或等于7，和你的产业深度应该小于或等于3，这对于人类毫无困难地理解是很好的。

在我看来，文件的限制应该是它的责任。每个文件都应该要求它自己的类，每个类都应该有一个责任。

Answer 6

在每个源文件中太少会有太多太糟糕 - 混乱只会从单个源文件移动到项目本身。

当我注意到源文件开始处理两个（或更多）明确分离的方面时，我倾向于将其分开。

如果我有一种感觉，它包含的功能可能在将来会被很多修改，同时也具有可能稳定的功能，我也会将其分开。