单独文件中的 C# 类？

C# classes in separate files?

提问by Chris

Should each class in my C# project get its own file (in your opinion)?

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

采纳答案by FlySwat

While the one class per file policy is strictly enforced in Java, it's not required by C#. However, it's generally a good idea.

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

I typically break this rule if I have a very small helper class that is only used by the main class, but I prefer to do that as a nested inner class for clarity's sake.

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

You can however, split a single class into multiple files using the partialkeyword. This is useful for separating your code from wizard-generated code.

但是，您可以使用partial关键字将单个类拆分为多个文件。这对于将您的代码与向导生成的代码分开非常有用。

回答by Oli

Public classes: yes Private classes: (needless to say) no

公共课程：是 私人课程：（不用说）没有

回答by Bill the Lizard

It depends. Most of the time I would say yes, put them in separate files. But if I had a private helper class that would only be used by one other class (like a Linked List's Node or Element) I wouldn't recommend separating them.

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

回答by Chris Wenham

Files are cheap, you aren't doing anyone a favor by consolidating many classes into single files.

文件很便宜，将许多类合并到单个文件中对您没有任何帮助。

In Visual Studio, renaming the file in Solution Explorer will rename the class and all references to that class in your project. Even if you rarely use that feature, the cheapness of files and the ease of managing them mean the benefit is infinitely valuable, when divided by its cost.

在 Visual Studio 中，在解决方案资源管理器中重命名文件将重命名项目中的类以及对该类的所有引用。即使您很少使用该功能，文件的廉价和易于管理也意味着，当除以成本时，收益是无限宝贵的。

回答by Simon Buchan

I actually prefer pretty big .cs files, 5000 lines is pretty reasonable IMO, although most of my files at the moment are only about 500-1000 (In C++, however, I've had some scary files), however, . The Object Browser/Class View, Go to Definition, and incremental search (-I; Thanks for that tip, Jeff Atwood!), all make finding any specific class or method pretty easy.

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

This is probably all because I am terrible about closing unneded tabs.

这可能是因为我对关闭不需要的选项卡感到很糟糕。

This is of course highly dependant on how you work, but there are more than enough tools to not need to use horrible old '70s based filesource navigation (Joking, if it wasn't obvious).

这当然高度依赖于您的工作方式，但是有足够多的工具不需要使用基于 70 年代的可怕的旧文件源导航（开玩笑，如果不明显的话）。

回答by ElGringoGrande

Of course! Why wouldn't you? Other than private classes it is silly to have multiple classes in a single file.

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

回答by flukus

They should be in different files, even when it seems like overkill. It's a mistake I still frequently make.

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

There always comes a time when you you've added enough code to a class that it deserves it's own file. If you decide to create a new file for it at that point then you lose your commit history, which always bites you when you lest want it too.

当您向类添加了足够多的代码时，总会有一段时间它值得拥有自己的文件。如果您决定在那时为其创建一个新文件，那么您将丢失提交历史记录，当您不想要它时，它总是会咬您。

回答by Jon Skeet

As others have said, one file per type in general - although where others have made the public/private distinction, I'd just say "one top-level file per type" (so even top-level internal types get their own files).

正如其他人所说，一般每种类型一个文件 - 尽管其他人已经区分了公共/私人，但我只想说“每种类型一个顶级文件”（因此即使顶级内部类型也有自己的文件） .

I have one exception to this, which is less relevant with the advent of the Func and Action delegate types in .NET 3.5: if I'm defining several delegate types in a project, I often bunch them together in a file called Delegates.cs.

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

There are other very occasional exceptions too - I recently used partial classes to make several autogenerated classes implement the same interface. They already defined the appropriate methods, so it was just a case of writing:

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

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

etc. Putting all of those into their own files would have been slightly silly.

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

One thing to bear in mind with all of this: using ReSharper makes it easier to get to your classes whether they're in sensibly named files or not. That's not to say that organising them properly isn't a good thing anyway; it's more to reinforce the notion that ReSharper rocks :)

所有这些都需要牢记一件事：使用 ReSharper 可以更轻松地访问您的类，无论它们是否位于合理命名的文件中。这并不是说适当地组织它们无论如何都不是一件好事。更多的是强化 ReSharper 摇滚的概念:)

回答by Wes Haggard

I personally believe that every class should be in its own file, this includes nested types as well. About the only exceptions to this rule for me are custom delegates.

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

Most answers have excluded private classes from this rule but I think those should be in their own file as well. Here is a pattern that I currently use for nested types:

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

Foo.cs: // Contains only Foo implementation

Foo.cs: // 只包含 Foo 实现

public partial class Foo 
{
   // Foo implementation
}

Foo.Bar.cs: // Contains only Foo.Bar implementation

Foo.Bar.cs: // 只包含 Foo.Bar 实现

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

回答by Tristan Fabrini

I think the one-class-per-file approach makes sense. Certainly for different classes, but especially for base and derived classes, whose interactions and dependencies are often non-obvious and error-prone. Separate files makes it straightforward to view/edit base and derived classes side-by-side and scroll independently.

我认为每个文件一个类的方法是有道理的。当然对于不同的类，但特别是对于基类和派生类，它们的交互和依赖项通常不明显且容易出错。单独的文件使查看/编辑基类和派生类并独立滚动变得简单。

In the days of printed source code listings running to many hundreds of pages (think of a phone book), the "three finger rule" was good a working limit on complexity: if you needed more than three fingers (or paper clips or post-its) as placeholders to understand a module, that module's dependency set was probably too complex. Given that almost no one uses printed source code listings anymore, I'll suggest that this should be updated as the "three window rule" - if you have to open more than three additional windows to understand code displayed in another window, this code probably should be refactored.

在打印源代码清单长达数百页（想想电话簿）的时代，“三指规则”是复杂性的有效限制：如果您需要三个以上的手指（或回形针或后它）作为理解模块的占位符，该模块的依赖集可能太复杂了。鉴于几乎没有人再使用打印的源代码清单，我建议将其更新为“三窗口规则”-如果您必须打开三个以上的附加窗口来理解另一个窗口中显示的代码，则此代码可能应该重构。

A class hierarchy of more than four levels is a code smell, which is in evidence if you need more than four open windows to see the totality of its behavior. Keeping each class in its own file will improve understandability for depth less than four and will give an indirect warning otherwise.

超过四个级别的类层次结构是一种代码异味，如果您需要四个以上打开的窗口来查看其行为的全部内容，则很明显。将每个类保留在自己的文件中将提高深度小于 4 的可理解性，否则将给出间接警告。