在一个文件中包含多个类定义是一种好习惯吗？或者每个文件最多有一个类？
答案 0 :(得分：17)
我更喜欢每个文件一个类。您永远不必搜索正确的文件名，因为它始终是类名。
答案 1 :(得分：6)
每个文件一个类。
这样，当两个人必须编辑同一个文件时，您可以避免必须合并编辑，因为一个人正在处理class A而另一个正在处理class B。虽然这在任何源控制系统中应该是自动的，但这是一个可以错过的额外步骤，这会导致问题。
最好让一个进程不允许首先发生这种错误。
答案 2 :(得分：5)
我没有看到同一文件中多个类有任何问题，只要这些类彼此相关即可。
如果您有resharper，您可以随时使用导航工具查找任何课程。
答案 3 :(得分：4)
通常最佳做法是每个班级有一个文件。
有些人，不是我，如果他们相关且非常小，他们喜欢拥有更多的人。其他人可能会在原型设计阶段这样做。我说开始并保持每个文件一个，斯科特麦康奈尔在他的开创性着作中对班级质量的讨论Code Complete
引用，“将一个类放在一个文件中。一个文件不仅仅是一个包含一些代码的存储桶。如果你的语言允许，一个文件应该包含一组支持一个且只有一个的例程目的。一个文件强化了一组例程在同一个类中的想法。“
答案 4 :(得分：3)
我认为最好每个文件都有一个类，并将它们组织在与命名空间具有相同层次结构的文件夹中。
答案 5 :(得分：3)
大多数程序员会认为每个文件一个类是最佳实践。
答案 6 :(得分：2)
通常 - 不。 按照惯例“每个文件一个类”简化了解决方案的浏览。 此外，如果你有一个庞大的开发人员团队和使用悲观方法（独占锁）的源代码控制工具 - 你的开发人员在处理同一个文件时会遇到困难。
答案 7 :(得分：1)
我想，正如你所说，这取决于偏好。 我想你会发现大多数在线示例/大多数代码都是每个文件一个类，以便于管理。
我有时会在文件中放两个类 - 只有当我使用第二个类作为实体并且它只在第一个类中使用时。
答案 8 :(得分：1)
我猜你问，因为你已经注意到它被认为是最好的做法。鉴于明显的好处（以及这里提到的一些不太明显的好处），你为什么要以不同的方式做到这一点？每个文件的多个类都有任何好处吗？我想不出任何一个。
答案 9 :(得分：1)
通常这是每个文件有一个类的最佳解决方案（文件名称与包含的类完全相同）。
我与
相比答案 10 :(得分：0)
我会说不，我知道devexpress也讨厌它（它有一些检测不好的人）。
但我确实有它，当它是一个非常小的类，基本上只用于文件中的“main”类。 Personaly我觉得它有点尝试，在你的项目中有10k行长的.cs文件或者有很多.cs之间存在平衡。
答案 11 :(得分：0)
我认为就“最佳实践”方法而言，可能是肯定的。但是，真的取决于项目。我倾向于将相关代码分组到单独的单元中，例如：
MyApplication.Interfaces
MyApplication.Utils
MyApplication.Controllers
我真的认为一个班级只有在它变得巨大的时候才值得拥有自己的单位。但是，如果它确实进入了这个阶段，你应该开始考虑将一些代码移动到辅助类中以分离逻辑。
答案 12 :(得分：0)
我最不同意这一点。每个文件一个类是理想的。它使得更容易看到项目中可用的内容，而不必依赖intellisense来发现给定程序集中可用的类型。
我认为我唯一一次吝啬每个文件规则的一个类就是当我定义一个自定义的EventArgs类时，它与从另一个类触发的事件有关。然后我通常会在同一个文件中定义这些事件的委托。我不知道这种方式是一种好习惯，还是仅仅是出于纯粹的懒惰？
答案 13 :(得分：0)
如果您处理的是非常大的项目，那么太多的文件会显着减慢构建时间（至少使用C ++）。我认为严格遵守规则不一定是必须走的路。
答案 14 :(得分：0)
每个文件一个类是我的首选方法，它可以帮助我摆脱以后的任何混淆......我倾向于使用很多部分类但是...
答案 15 :(得分：0)
只要我没有打破1000线障碍，我就会填充许多有意义的相关课程。
有时抽象可能只是一种被覆盖的方法。