.NET中每个文件规则有一个类？
我遵循这个规则，但是有些同事不同意这个观点，认为如果一个class级比较小，可以和其他class级放在同一个档案里。
我一直听到的另一个说法是：“即使微软不这样做，为什么我们呢？”
对此有何共识？ 有没有这种情况应该避免？
每个文件一个类也给你一个更好的概念，看看每个检查是在改变，而不看文件的差异。
当人们认为绝对的时候我讨厌它，并且说你不应该用这样的主观和挑剔的东西来做这个或那样的事情，就好像我们都需要去顺应某些愚蠢的是非的想法。 底线：每个文件有多个类是完全没有问题的。 有道理，我的意思是说：
- 使代码更容易消化和维护
- 使解决scheme不那么烦人（滚动浏览无数不必要的文件），并减慢速度
- 开发团队可以将其作为本地编码实践
一个很好的例子，为什么我可能需要每个文件多个类：
假设我有几十个自定义的exception类，每一个都是一个4class，我可以有一个单独的文件，或者我可以将exception分组，每组有一个文件。 对我来说，最合理/实用的方法是把它们分组，并且只是有几个文件，因为它更有效的时间/编码明智（我不必右键单击 – >添加类，重命名，50倍） ，这样可以使解决scheme更简洁，更好地执行。
static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase) { return (rule.Overhead(useCase) < My.PersonalThresholds.ConformismVsPracticality); } 如果他们紧密耦合，并且其中至less有一个非常小，我有时会在一个文件中分组多个类。
一般的“最佳做法”是每class有一个档案。
除了假设性的论点，并将注意力集中在使用Visual Studio IDE和不断增长的软件项目的Windows .NET上之外，在这种情况下，每个文件只有一个类是有道理的。
一般来说， 对于视觉参考而言，每个文件都不会有一个类别。 真。
我不知道微软是否做同样的事情，但他们确实创build了partial关键字来将一个类拆分成多个文件 （这更加严重）。 它通常用于在同一个类中将自动生成的devise器代码从自定义代码中分离出来（但有时用于允许不同的开发人员通过不同的文件同时处理类）。 所以微软确实看到了多个文件的好处，而且每个人都有多个文件组织的想法。
对于嵌套类，你别无select，只能使用一个文件，或者至less使用一个文件的第一部分。 在这种情况下，一个文件是必要的，罚款：
class BicycleWheel { class WheelSpoke { } }
否则，为什么要在一个文件中保留多个类？ “因为他们很小”或相互关联的论点并没有太多的用水，因为最终你的课程将与其他课程相关联。 最终，您不能轻松推断基于其用法的对象的文件内组织，特别是随着软件的不断发展。
另外，如果你使用命名空间的文件夹，那么你永远不会有类文件名冲突。 当不在像Visual Studio这样的开发环境内时（例如， 如果你想用记事本或快速/快速的方式快速编辑一个类）， 在文件系统上按文件名find一个类也是很方便的。
这么多好的理由
在绝大多数情况下，我遵循每个文件规则的一个类。 我经常做的唯一例外就是定义一个与特定类相关的枚举。 在这种情况下，我会经常把enum的定义包含在这个类的文件中。
我也相信应该有一个types包含在一个文件中。
有一个例外，这个规则必须提到：有两个类只有一个generics的参数不同，如：
RelayCommand
和
RelayCommand<T>
在更大的解决scheme中，我认为每个文件有一个类是非常有价值的，并且该文件与类相同。 这使得find你需要的代码更容易。
用于C＃的StyleCop工具具有标准规则，在一个名称空间中只需要一个顶级类（在该名称空间中加上任意数量的接口，委托和枚举）。
在第二类和后续类仅被第一类使用的两个或更多类的情况下，那些类可以并且应该是内部类，仅对消费类可见。
我发现在同一个文件中将它与标准工厂类分组是非常有用的。
我通常每个文件都有一个类，但是你通常必须使用自己的判断来查看这个文件是否可以包含相关的类，例如将你自己和其他开发者可以重用的exception分组。 在这种情况下，用户只需要包含一个文件而不是多个文件。
所以重点是： 谨慎应该使用！
真的，这归结为个人喜好。 每个人都会说“每档一档”，但在某些情况下我们都有我们的理由来避免这种情况。 我曾经有一个大型项目，有大约300个不同的枚举。 我不可能有300个单独的文件，每个类一个，当一些枚举只是三态。
对于那些找不到某些类的人来说，如果他们不是全部以他们的名字命名的文件，那么是否有一个原因，您没有使用Find来查看整个解决scheme？ 使用“查找”可以节省我在“解决scheme资源pipe理器
无论内容如何轻量，我认为每个文件的一个类/接口/等是必不可less的。
如果我正在Visual Studio中处理一个大的解决scheme，我希望能够看到这些文件，而不必深入研究。 即使使用像ReSharper这样的导航工具，我也想要1：1的映射。
如果你发现许多内容很less或没有内容的源文件（也许扩展一个类，但没有增加任何内容），那么也许你应该重新考虑你的devise。
有时每个文件只有一个类， 但是 …
当多个类严格相关时，相同源文件中的多个类比恕我直言，优于为每个类指定一个短源文件。 源代码更具可读性和紧凑性（并且使用#region，相同的源代码可以比以前更具结构化）。
考虑到有些时候需要在不同的文件中传播相同的类（使用部分文件），因为有了20000多行的源代码文件，即使我有可用的RAM也不方便（但这是另一个问题）。
有时我会留下一个较大的class级，但只有当他们像一个对象非常紧密相关，它是收集类或工厂。
这个有一个问题。 最终，小class人数增长到应该在自己的文件中，如果你把它移动到新的文件，你会失去方便访问你的修订历史logging。
即。
- 星期一，我对文件y.css中的类x和y进行了更改
- 在星期二我将x类分离到它自己的文件x.css中，因为它已经变大了
- 在星期三，我的老板想要看看我在星期一改变了什么，所以他看着x.css的历史，只有x.css在星期二变化之前不显示历史。
这真的是个问题吗？:)
真正的小class，就像枚举一样，可以和其他人放在一起。 有一条规则可以遵循：把只有有共同点的类放在一起。
作为一个题外话 – 在我的一个项目中，我有一个内部有150个类的文件。 该文件具有10000行代码。 但它是自动生成的，所以它是完全可以接受的:)
将多个相关类放在一个文件中的一个原因是，使用您的API的可怜的混蛋不必花费半天的时间打印import声明样板文件，而需要维护代码的可怜的混蛋不必花费一半一天滚动import报关样板。 我的经验法则是，如果您几乎总是在同一时间使用它们的大部分子集，而不是一次只使用一个，则多个类属于同一个文件。
我这样做，但只有当这些类是以父母方式相关的时候，而且这些孩子类只能被父母使用。
对每个文件的另一个类进行投票，并将该文件命名为与该类相同的文件。 对我来说，它有助于长期的可维护性。 我可以轻松查看存储库，查看哪些类是解决scheme的一部分，而无需打开项目或任何文件。
我遵循99％的时间。 遵循标准是很好的，但我也相信灵活性有其地位。 有时候，把事情分开，似乎是一种愚蠢的浪费。 在那个时候，我自己解决了，只是写我的代码。
到目前为止的回应似乎围绕着人们对规则的例外，所以这里是我的：在.NET3.5 SP1中使用DataAnnotations包时，我将类和它们的元数据“伙伴”类保持在一起。 否则，他们总是在单独的文件。 你知道，大部分时间。 除非他们没有。
我只做这个很less。 例如，如果有一个枚举或结构与类非常相关，但又太小而无法自行分离。
或者一个单独的类来包含该主类的一些扩展方法。
One case could be:当你的class级共同组成一个module / unit ，为helper classes等主要class级提供服务时，
看看ASP.NET MVC 2.0项目的源代码。 严格遵循这个规则
我通常坚持每个文件一个类。 但是我会为项目范围内使用的类似结构的组提供例外。 例如：
- 一个包含任何
EventArgs子类的EventArgs，因为它们通常只有5-10行代码，但是它们通常被几个不同的类使用。 或者，我可能会把EventArgs类放在与声明事件的类相同的文件中。 - Delegates.cs包含在整个项目中使用的委托，因为它们通常只有一行。 再次，另一种方法是将它们放在与暴露/使用它们的类相同的文件中。
- 包含整个项目中使用的
enum的Enums.cs。 （如果有一个只有一个类使用的enum，我通常会把它用于这个类。
我喜欢创build更小的class级，并确保class级只做它应该做的事情。 如果您有多个课程有助于解决单个问题，那么将它们放在同一个文件中就没有什么坏处。
我不会遵循微软的做法，因为他们不是最好的做法！
来回一直很有趣，看起来没有结果，虽然我的一般印象是，在class级和档案之间的1-1映射是多数意见，虽然有一些个人的例外。
我很好奇，如果你的答案有所不同，取决于你是否：（1）开发一个Windows窗体应用程序，Web应用程序，图书馆，或任何; 或者（2）使用Visual Studio或不使用。 在使用VS时，看起来每个文件规则中的一个类也意味着每个VS项目有一个类，因为其他线程中的共识似乎是应该在目录/文件命名和结构中镜像VS解决scheme/项目。 事实上，我的印象是共识是项目名称=程序集名称=（嵌套）名称空间名称，所有这些名称将被镜像到目录/文件的命名和结构中。 如果这些是正确的准则（或规则），那么所有这些看起来正交的组织机制将保持同步。
是的，为了可读性，我们应该有一个文件每class！ 刚刚跳进一个项目。 我在一个文件中看到很多类。 这让新人很难理解。 我们是否应该考虑可维护性？ 当我们开发一个软件？ 其他开发人员将继续多次开发。 我们有命名空间来安排我们的东西，我们不需要文件来做到这一点！
每个文件一个代码项，是的。
其他一切都是不当行为 – 坦率地说，这是RAD受害者的标志。
一旦开始适当的软件开发（IoC，devise模式，DDD，TDD等等），并留下“omg让这个完成，我不知道如何，但我得到报酬”的游乐场，人们会看到这个规则真的很重要。
