在单独的文件中的C＃类？
我的C＃项目中的每个类是否应该获得自己的文件（在您的意见中）？
虽然每个文件一个类的策略在Java中严格执行，但C＃并不要求这样做。 但是，这通常是一个好主意。
如果我有一个只由主类使用的非常小的帮助类，通常会打破这个规则，但为了清楚起见，我更喜欢将其作为嵌套的内部类来实现。
但是，您可以使用partial关键字将单个类拆分为多个文件。 这对于将代码与向导生成的代码分开很有用。
文件很便宜，你不会把许多类整合到单个文件中。
在Visual Studio中，在解决scheme资源pipe理器中重命名该文件将重命名该类以及项目中该类的所有引用。 即使你很less使用这个function，文件的便宜性和pipe理它们的方便性也意味着，除了成本之外，这个好处是无限的。
正如其他人所说的，每种types的文件一般来说 – 尽pipe其他人已经做出了公/私的区别，但我只是说“每个types有一个顶级文件”（即使顶级内部types也能获得自己的文件） 。
我有一个例外，这与.NET 3.5中Func和Action委托types的出现不太相关：如果我在一个项目中定义了几个委托types，我经常把它们放在一个名为Delegates.cs的文件中。
还有其他非常偶然的例外 – 我最近使用部分类来使几个自动生成的类实现相同的接口。 他们已经定义了适当的方法，所以这只是一个写作的例子：
public partial class MessageDescriptor : IDescriptor<MessageDescriptorProto> {} public partial class FileDescriptor : IDescriptor<FileDescriptorProto> {}
把所有这些放到他们自己的档案中会有些愚蠢。
有一件事需要牢记：使用ReSharper可以更容易地到达您的类，无论它们是否在明智的命名文件中。 这并不是说组织好他们不是好事， 这更加强化了ReSharper的观点:)
我个人认为，每个类都应该在自己的文件中，这也包括嵌套types。 关于这个规则的唯一例外是自定义代表。
大多数答案已经排除了这个规则的私人class，但我认为这些也应该在他们自己的文件中。 这里是我目前使用嵌套types的模式：
Foo.cs：//仅包含Foo实现
public partial class Foo { // Foo implementation }
Foo.Bar.cs：//仅包含Foo.Bar实现
public partial class Foo { private class Bar { // Bar implementation } }
这取决于。 大多数时候我会说是，把它们放在单独的文件中。 但是，如果我有一个私人助手类，只能被其他类使用（如链接列表的节点或元素），我不build议分开它们。
他们应该在不同的文件，即使它看起来像矫枉过正。 我仍然经常犯这个错误。
总是有一段时间你已经向课堂添加了足够的代码，而这个代码是自己的文件。 如果你决定在那个时候为它创build一个新的文件，那么你会失去你的提交历史logging，当你不需要的时候，它总会咬你。
公开课：是私人课:(不用说）
我其实更喜欢漂亮的.cs文件，5000行是非常合理的海事组织，虽然目前我的大部分文件只有大约500-1000（但在C ++中，我有一些可怕的文件）。 对象浏览器/类视图，转到定义和增量search（-I;谢谢你的提示，杰夫·阿特伍德！），都使find任何特定的类或方法很容易。
这可能都是因为我closures无标签的标签。
这当然很大程度上取决于你的工作方式，但是有足够多的工具不需要使用可怕的70年代的文件源导航（如果不是很明显的话）。
作为一个在大文件编码多年（限制在1000行）的人，事实上，自从我开始编程时，我对这个“每个源文件一个类”规则的巨大共识感到惊讶。
“每个源文件一个类”并非没有问题。 如果你一次处理很多事情，你会打开很多文件。 当然，您可以在完成文件后closures文件，但是如果需要重新打开它们呢？ 每次打开文件通常都会有延迟。
我现在要解决其他人的观点，并解释我认为是“一个源文件一类”规则的不好的理由。 现代源码编辑技术解决了一个源文件中多个类的问题。
- “我讨厌上下滚动” – 糟糕的原因 – 现代IDE现在要么有内置的function，以便快速获得所需的代码，要么可以安装扩展/插件。 Visual Studio的解决scheme资源pipe理器通过其searchfunction执行此操作，但如果这还不够，请购买VisualAssist。 VisualAssist提供了源文件中项目的大纲。 不需要滚动，但双击你想要的。
还有代码折叠。 代码太多？ 把它合并成一行！ 问题解决了。
-
“事情更容易find，因为它们是由文件识别” – 错误的理由 – 再次，现代IDE可以很容易地find你要找的东西。 只需使用解决scheme资源pipe理器或购买VisualAssist！ 技术在那里，使用它！
-
“容易阅读/太多的代码” – 错误的理由 – 我不是盲目的。 我可以看到。 同样，通过代码折叠，我可以轻松消除混乱，并折叠我不需要看到的代码。 这不是编程的石器时代。
-
“你会忘记在大型项目中的类” – 错误的原因 – 简单的解决scheme：Visual Studio中的解决scheme资源pipe理器和VisualAssist扩展。
-
“你知道什么是一个项目，而不打开任何东西” – 好理由 – 没有任何争议。
-
源代码pipe理/合并 – 好理由 – 这实际上是支持“每个源文件一个类”规则的一个很好的理由，特别是在团队项目中。 如果有多个人在同一个项目上工作。 它让人们一眼就能看到变化。 如果您使用大型，多类文件，我也可以看到如何使合并过程复杂化。
源代码控制和合并过程实际上是唯一有说服力的理由IMO，即“每个源文件一个类别”规则应该适用。 如果我在自己的个人项目上工作，不，这不重要。
当然！ 你为什么不呢？ 除了私有类以外，在单个文件中有多个类是愚蠢的。
我认为一个一个文件的方法是有道理的。 当然，对于不同的类，特别是对于基类和派生类，它们的交互和依赖通常是不明显的，并且容易出错。 单独的文件可以直接查看/编辑基本类和派生类并独立滚动。
在打印源代码列表运行到数百页的时代（想到电话簿），“三指规则”对于复杂性来说是一个很好的工作限制：如果你需要三个以上的手指（或者纸夹或者后处理程序）它）作为占位符来理解一个模块，那个模块的依赖集可能太复杂了。 鉴于几乎没有人使用打印的源代码列表了，我会build议这应该被更新为“三个窗口规则” – 如果你必须打开三个以上的窗口来了解另一个窗口中显示的代码，这个代码可能应该重构。
超过四个级别的类层次结构是一种代码异味，如果您需要四个以上的打开窗口来查看其整个行为，那么这是一个明显的证据。 保持每个class级在自己的文件将提高深度less于四的可理解性，并会给予一个间接的警告，否则。
