在一个文件中有多个类定义是一个好的实践吗?

我喜欢每个文件一个类。您永远不必搜索正确的文件名,因为它总是类名。

每个文件一个类。

这样,当两个人必须编辑同一个文件时,您可以避免合并编辑,因为其中一个人正在处理 class A 另一个正在努力 class B .虽然这在任何源代码管理系统中都应该是自动的,但这是一个可以忽略的额外步骤,这会导致问题。

最好有一个不允许这种错误首先发生的过程。

我不认为同一个文件中的多个类有任何问题,只要这些类彼此相关。

如果您有Resharper,则可以始终使用导航工具查找任何类。

一般来说,每个类有一个文件是最佳实践。

有些人,不是我,如果他们有亲戚关系,而且体型很小的话,他们喜欢不止一个。其他人可能会在原型阶段完成这项工作。就像斯科特·麦康奈尔(Scott McConnell)在其开创性著作中关于阶级品质的论述中所说的那样,每个文件都有一个开始和保持。 Code Complete

引述, “在一个文件中放入一个类。文件不仅仅是一个存储一些代码的桶。如果您的语言允许,那么一个文件应该包含一个支持一个且只有一个目的的例程集合。一个文件强化了这样一种思想:一组例程在同一个类中。”

我认为最好每个文件都有一个类,并将它们组织在与其名称空间具有相同层次结构的文件夹中。

大多数程序员会认为每个文件一个类是一种最佳实践。

通常不是。 遵循实践“每个文件一个类”简化了解决方案的浏览。 此外,如果您有一个庞大的开发人员团队和使用悲观方法(排他锁)的源代码管理工具,那么您的开发人员在处理同一个文件时将很困难。

我想这取决于你说的偏好。 我想您会发现大多数在线示例/大多数代码是每个文件一个类,以便于管理。

我有时会在一个文件中放置两个类——只有当我使用第二个类作为一个实体并且它只在第一个类中使用时。

我想你问是因为你已经注意到它被认为是最佳实践。考虑到显而易见的好处(以及这里提到的一些不那么明显的好处),为什么您要以不同的方式来做呢?每个文件有多个类的好处吗?我想不出任何。

通常 最好的解决方案是每个文件有一个类(文件名与包含的类完全相同)。

我只 相异 从如果

• 有很多小的枚举-我将它们收集到一个文件中,例如enums.cs。
• 生成的类/接口有很多(20多个)直接相互关联,例如interfaces.cs文件
• 有一些东西不是应用程序的直接功能部分,并且在语义上紧密一致(例如,互操作所需的一切)。这通常是一些结构、枚举、常量和单个类)->它们进入以interop类命名的单个文件中。
• 私有内部类--保留在其父类而不是部分类中

我会说不,我知道DevExpress也讨厌它(它有一些检测不良的行为)。

但有时我确实会用到它,因为它是一个非常小的类,基本上只被文件中的“主”类使用。从个人角度来说,我觉得这有点让人失望,在拥有10公里长的.cs文件和项目中的许多.cs文件之间有一个平衡。

我认为,就“最佳实践”方法而言,可能是的。然而,这确实取决于项目。我倾向于将相关代码分组为单独的单元,例如:

MyApplication.Interfaces
MyApplication.Utils
MyApplication.Controllers

我真的认为一个班级只有在它变得巨大的时候才配得上它自己的单元。但是,如果它确实到达了这个阶段,您应该开始考虑将一些代码移动到助手类中,以分离逻辑。

我不得不同意大多数人的意见。每个文件一个类是理想的。它使查看项目中可用的内容更加容易,而无需依赖IntelliSense来发现给定程序集中可用的类型。

我认为我唯一一次对每个文件一个类的规则敷衍的时候就是我定义了一个自定义的EventArgs类,它与从另一个类激发的事件相关。然后,通常我会在同一个文件中定义这些内容以及事件的委托。我不知道这是一种很好的练习,不管是从某种角度还是从纯粹的懒散中??

如果你在一个非常大的项目上工作,太多的文件会显著减慢你的构建时间(至少用C++)。我不认为严格遵守规则是必然的。

每个文件一个类是我的首选方法,它有助于我以后摆脱任何混乱…不过,我倾向于使用很多部分类…

只要我不打破1000行的障碍,我会在尽可能多的相关类有意义。

有时抽象可能只是一个被重写的方法。