我与我们公司的团队负责人\建筑师就这个话题进行了讨论。
他认为，如果将“逻辑连接的实体”放在一个 cs 文件中，则更容易理解大型项目。
我引用：
“整个逻辑结构、接口和类都可以在一个地方看到，这是一个无法反驳的论点。要看到同样的东西，但有一堆文件，你需要使用工具、类图表，用于导航的 R# 等。”
“按照这个糟糕的理论，我可能会尖叫说一大堆分离的文件很酷，但是当涉及到对现有代码进行更改时，特别是如果你不是这段代码的编写者，那么很难理解大量分散的文件。所以在论坛上，你可以写“一个枚举一个文件”，但在实践中，永远不应该使用这种方法“
“......关于开发人员之间的代码库分离，现在同时编辑同一个文件不是问题。合并不是问题。”
我多次听到并阅读到我们必须为每个枚举、类等创建一个 .cs 文件，这是最佳实践。
但我无法说服他。他说他不信任任何知名程序员，例如 Jon Skeet。顺便说一下，这里是 Skeet 对这个主题的看法定位枚举类型的最佳位置在哪里？
你怎么看？有真正的问题吗？还是口味问题，应该由组织的编码标准来规范？
在我看来：
较大逻辑类中所需的小型枚举和类可以保留在其文件中。
但是，如果在该范围之外使用较小的类和枚举，则应该单独使用它们（尽管如果它们在逻辑上链接，它们本身可能在同一个文件中）。
所以我同意他关于逻辑耦合的观点。
话虽如此，我必须说还有其他选择，您可以在项目内创建逻辑文件夹以保存来自相同逻辑环境或连接的类。
今天的 IDE 让您在整个解决方案中通过 Go-To 功能轻松访问和移动，因此查找代码不是问题。
将逻辑组件保持在一起（只要它们真正紧密耦合）在扩展时确实具有很大的优势。随着项目变得越来越大，它往往会变得更加混乱，而这正是他试图避免的。
顺便说一句，如果您仔细阅读 Skeet 的意见，您会注意到：
并假设它们将被其他类使用，在它们自己的文件中使它们成为顶级类型。
有趣的问题，这是我的看法。
您必须区分逻辑分组（命名空间）和物理分组（文件/项目）。
在任何情况下，枚举都应该放在它业务明智所属的逻辑命名空间中，而不是放在只包含枚举的命名空间中，或者甚至不要在命名空间名称中指定枚举。拥有“枚举”命名空间是没有意义的，因为您将混淆概念并且您没有指定它所属的域。
如果一个枚举只被一种类型的类使用，你也可以把它放在类本身中。这样，很明显它属于那个特定的类，因此它在同一个代码文件中。如果枚举更像是一个通用枚举，在多个类中使用，那么将它单独放在自己的代码文件中。
所以我不同意你的团队领导：如果你把它放在同一个文件中，让它成为类本身的一部分，因为如果你把它放在同一个文件中，这就是你所说的，否则把它放在它自己的代码文件中。我认为无论如何，它的用法更一致。
这在很大程度上是一个意见问题，因此最好在此处发布：
https://codereview.stackexchange.com/
但是，通常您应该将所有类型定义放在它们自己的文件中，但有一些例外：
用于为抽象基类或接口提供契约的代码契约类在逻辑上属于该类。
仅在类中用作参数、属性或返回值的枚举也属于该类（但不嵌套在其中）。
可能还有其他一些例外，但通常每种类型都应放入单独的文件中。
i think that your "teamlead\architect" opinion is largely based on poor usages of namespaces. every time I have heard that argument from a developer it is because of almost total lack of namespace usage(and then it becomes really messy if you add a lot of files)
我不同意这里的“团队负责人/架构师”提出的许多观点。
就像很多与代码有关的事情一样，这是一个见仁见智的问题。
就个人而言，我认为最好为每个枚举、类等创建一个 .cs 文件。通常，如果有一个类与枚举最密切相关，我会将它们放在同一个文件中。
我接受公司可以拥有自己的编码标准，但这里建议的标准是完全错误的，因为它违背了很多我认为的良好做法。
你和他可以看看互联网上大量复杂的开源项目。看看 github、codeplex 和类似的地方。
例如查看 MVC 源代码。如果每个文件的类对微软来说足够好并且像 MVC 一样复杂的项目，我认为它很有可能对你们也足够好。
就我个人而言，我使用每个文件的类/接口方法（在特殊情况下除外，比如有一点枚举，但这是主观的），我看不出它有任何问题。