Question

我的C＃项目中的每个类都应该获得自己的文件（在您看来）吗？

Answer 1

虽然每个文件的一个类策略在Java中是严格执行的，但C＃并不需要它。但是，这通常是一个好主意。

如果我有一个仅由主类使用的非常小的辅助类，我通常会违反此规则，但为了清楚起见，我更喜欢将其作为嵌套的内部类。

但是，您可以将单个类拆分为多个文件using the partial keyword。这对于将代码与向导生成的代码分开很有用。

Answer 2

文件很便宜，你可以通过将许多类合并为单个文件来帮助任何人。

在Visual Studio中，在解决方案资源管理器中重命名文件将重命名该类以及项目中对该类的所有引用。即使你很少使用这个功能，文件的便宜性和管理它们的便利性意味着当它除以成本时，这种好处是无限有价值的。

Answer 3

正如其他人所说的那样，每种类型一般都有一个文件 - 虽然其他人已经公开/私人区分，但我只是说“每种类型一个顶级文件”（所以即使是顶级内部类型也会得到他们的自己的文件）。

我有一个例外，它与.NET 3.5中Func和Action委托类型的出现不太相关：如果我在项目中定义了几个委托类型，我经常将它们聚集在一个名为的文件中Delegates.cs。

还有其他非常偶然的异常 - 我最近使用了部分类来使几个自动生成的类实现相同的接口。他们已经定义了适当的方法，所以这只是一个写作的例子：

public partial class MessageDescriptor : IDescriptor<MessageDescriptorProto> {}
public partial class FileDescriptor : IDescriptor<FileDescriptorProto> {}

等。将所有这些放入他们自己的文件中会有些愚蠢。

要记住所有这一切：使用ReSharper可以更轻松地访问您的类，无论它们是否在合理命名的文件中。这并不是说正确组织它们并不是一件好事;更重要的是要强化ReSharper摇滚的观念:)。

Answer 4

我个人认为每个类都应该在自己的文件中，这也包括嵌套类型。关于此规则的唯一例外是自定义委托。

大多数答案都排除了此规则中的私有类，但我认为这些也应该在他们自己的文件中。这是我目前用于嵌套类型的模式：

Foo.cs：//仅包含Foo实现

public partial class Foo 
{
   // Foo implementation
}

Foo.Bar.cs：//仅包含Foo.Bar实现

public partial class Foo
{
  private class Bar
  {
    // Bar implementation
  }
}

Answer 5

这取决于。大多数时候我会说是的，把它们放在单独的文件中。但是如果我有一个私有帮助器类只能被另一个类使用（比如链接列表的节点或元素），我不建议将它们分开。

Answer 6

它们应该在不同的文件中，即使它看起来有点过分。这是我经常犯的错误。

总有一段时间，你已经为类添加了足够的代码，它应该拥有它自己的文件。如果您决定在那时为它创建一个新文件，那么您将丢失您的提交历史记录，当您不想要它时，它总是会让您感到厌烦。

Answer 7

作为一个多年来一直在大文件中编码的人（限于1000行），事实上，自从我从小就开始编程以来，我对这个＆＃34;每个源文件一个类的巨大共识感到惊讶＃34;规则。

＆＃34;每个源文件一个类＆＃34;并非没有问题。如果您同时处理很多事情，您将打开许多文件。当然，您可以在完成文件后关闭文件，但是如果您需要重新打开文件呢？每次打开文件时都会有延迟。

我现在要解决其他人已经提出的要点并解释我认为每个源文件的一个类的错误原因＆＃34;规则。使用现代源编辑技术解决了一个源文件中多个类的许多问题。

＆＃34;我讨厌不得不向上和向下滚动＆＃34; - 糟糕的原因 - 现代IDE现在要么具有内置功能，可以快速获得所需的代码，也可以为该任务安装扩展/插件。 Visual Studio的解决方案资源管理器使用其搜索功能执行此操作，但如果这还不够，请购买VisualAssist。 VisualAssist提供源文件中项目的概述。无需滚动，只需双击您想要的内容即可。

还有代码折叠。代码太多了？把它折成一行吧！问题解决了。

＆＃34;事情更容易找到，因为它们是由文件＆＃34; - 糟糕的原因 - 同样，现代的IDE可以很容易地找到你正在寻找的东西。只需使用Solution Explorer或购买VisualAssist !!技术在那里，使用它！
＆＃34;更容易阅读/太多代码＆＃34; - 不好的理由 - 我不是盲目的。我可以看到。再次，通过代码折叠，我可以轻松地消除混乱并崩溃我不需要看到的代码。这不是编程的石器时代。
＆＃34;你会忘记班级在大型项目中的位置＆＃34; - 错误的原因 - 简单的解决方案：Visual Studio中的解决方案资源管理器和VisualAssist扩展。
＆＃34;你知道项目中的内容没有打开任何东西＆＃34; - 好理由 - 与那个没有争议。
源代码控制/合并 - 好理由 - 这实际上是支持每个源文件一个类的一个好参数＆＃34;规则，特别是在团队项目中。如果有多个人正在处理同一个项目。它让人们可以一目了然地看到变化。如果您使用大型多类文件，我还可以看到它如何使合并过程复杂化。

源控制和合并过程实际上是IMO唯一令人信服的理由，即每个源文件的一个类＃34;规则应该适用。如果我在自己的个人项目上工作，不，那就不那么重要了。

Answer 8

公共课：是的私人课程:(不用说）没有

Answer 9

我实际上更喜欢相当大的.cs文件，5000行是非常合理的IMO，虽然目前我的大多数文件只有大约500-1000（但是，在C ++中，我有一些可怕的文件），但是，。对象浏览器/类视图，转到定义和增量搜索（-I;感谢您的提示，Jeff Atwood！），所有这些都使得查找任何特定的类或方法非常容易。

这可能是因为关闭不需要的标签我很糟糕。

这当然在很大程度上取决于你的工作方式，但是有足够多的工具不需要使用可怕的旧的基于70年代的文件源代码导航（开玩笑，如果不明显的话））。

Answer 10

当然！你为什么不呢？除了私有类之外，在单个文件中包含多个类是很愚蠢的。

Answer 11

我认为每个文件的一类方法是有道理的。当然对于不同的类，但特别是对于基类和派生类，其交互和依赖性通常不明显且容易出错。单独的文件可以直接并排查看/编辑基类和派生类，并可以单独滚动。

在打印源代码列表运行到数百页（想到电话簿）的时代，＆＃34;三指规则＆＃34;在复杂性方面是一个很好的工作限制：如果你需要三个以上的手指（或纸夹或后贴）作为占位符来理解一个模块，那么该模块的依赖集可能过于复杂。鉴于几乎没有人再使用打印的源代码列表，我建议将其更新为＆＃34;三窗口规则＆＃34; - 如果你必须打开三个以上的额外窗口来理解另一个窗口中显示的代码，这个代码可能应该被重构。

超过四个级别的类层次结构是一种代码气味，如果您需要超过四个打开的窗口来查看其行为的总体情况，则可以证明这一点。将每个类保存在自己的文件中将提高深度小于4的可理解性，否则将给出间接警告。

C＃类在单独的文件中？

11 个答案: