是否应将类，枚举和其他实体放在单独的文件中？

我公司的团队负责人\建筑师认为，如果将“逻辑连接的实体”放在一个.cs文件中，则大型项目更容易理解。

我引用：

• “逻辑，接口和类的整体结构可以在一个地方看到，这是一个不能被驳斥的论点。要看到同一件事，但需要一堆文件，则需要使用工具，类图，R＃用于导航，等等。”

• “遵循拙劣的理论，我可能会大声疾呼，分开的文件很酷，但是当涉及到对现有代码进行更改时，尤其是如果您不是该代码的编写者时，很难理解大量分散的文件。因此，在论坛上，您可以编写“一个枚举一个文件”，但实际上，永远不要使用这种方法“

• “ ...关于开发人员之间代码库的分离，如今同时编辑同一文件已不是问题。合并已不是问题。”

我听说过很多次，我们必须为每个枚举，类等创建一个.cs文件，这是最佳实践。

但是我不能说服他。他说，他不信任任何著名的程序员，例如Jon Skeet。顺便说一下，Skeet对这个主题的看法是：找到枚举类型的最佳位置在哪里？

你怎么看？有真正的问题吗？还是只是一个口味问题，应该由组织的编码标准来规范？

团队负责人的论点存在两个缺陷：

1. 设计良好的类和枚举旨在在项目中的任何地方使用，而不仅仅是在逻辑上有意义的地方。

2. 用XML注释正确记录的类和枚举非常自我描述，只需将鼠标悬停在引用它的项目上即可。

3. 始终可以通过右键单击引用并选择“转到定义”来获得类或枚举的定义，因此放置在什么地方都没关系。

4. 以“逻辑”方式将对象放在一起是任意的（即，您必须考虑“逻辑”的含义。我宁愿花费那些时钟周期进行实际编程）。

在其自己的文件中设置每个对象定义会产生对组织和结构的统一，有纪律的期望，并且不会引发诸如“为什么在这里？这是一件非常美好的事情。

如果两个或多个对象在逻辑上相关，则只需将它们放在项目浏览器中自己的文件夹中。

团队负责人很可能在更早的时代咬了牙，当时右键单击并选择“转到定义”不是一个选择。我知道当我处于严重的峰值开发模式时，我会增长大量的类文件，直到让resharper替我修复它为止。

无论如何，如果您想带领团队完成任务，请问他为什么这些类和枚举不是子类和枚举-如果它们是真正的依赖实体，则没有理由将它们声明为独立实体。这可能会帮助他稍微思考一下这个法特瓦。