C# 解决方案中的文件夹是否应该与命名空间匹配？

Should the folders in a solution match the namespace?

提问by

Should the folders in a solution match the namespace?

解决方案中的文件夹是否应该与命名空间匹配？

In one of my teams projects, we have a class library that has many sub-folders in the project.

在我的一个团队项目中，我们有一个类库，项目中有许多子文件夹。

Project Name and Namespace: MyCompany.Project.Section.

项目名称和命名空间：MyCompany.Project.Section.

Within this project, there are several folders that match the namespace section:

在这个项目中，有几个与命名空间部分匹配的文件夹：

• Folder Vehicleshas classes in the MyCompany.Project.Section.Vehiclesnamespace
• Folder Clothinghas classes in theMyCompany.Project.Section.Clothingnamespace
• etc.

• 文件夹Vehicles在MyCompany.Project.Section.Vehicles命名空间中有类
• 文件夹Clothing在MyCompany.Project.Section.Clothing命名空间中有类
• 等等。

Inside this same project, is another rogue folder

在同一个项目中，是另一个流氓文件夹

• Folder BusinessObjectshas classes in the MyCompany.Project.Sectionnamespace

• 文件夹BusinessObjects在MyCompany.Project.Section命名空间中有类

There are a few cases like this where folders are made for "organizational convenience".

有一些像这样的文件夹是为了“组织方便”而制作的。

My question is: What's the standard? In class libraries do the folders usually match the namespace structure or is it a mixed bag?

我的问题是：标准是什么？在类库中，文件夹通常与命名空间结构匹配还是混合包？

采纳答案by Lasse V. Karlsen

Also, note that if you use the built-in templates to add classes to a folder, it will by default be put in a namespace that reflects the folder hierarchy.

另请注意，如果您使用内置模板将类添加到文件夹，则默认情况下它将被放置在反映文件夹层次结构的命名空间中。

The classes will be easier to find and that alone should be reasons good enough.

这些课程将更容易找到，仅此一项就足够了。

The rules we follow are:

我们遵循的规则是：

• Project/assembly name is the same as the root namespace, except for the .dll ending
• Only exception to the above rule is a project with a .Core ending, the .Core is stripped off
• Folders equals namespaces
• One type per file (class, struct, enum, delegate, etc.) makes it easy to find the right file

• 项目/程序集名称与根命名空间相同，但以 .dll 结尾
• 上述规则的唯一例外是具有 .Core 结尾的项目，.Core 被剥离
• 文件夹等于命名空间
• 每个文件的一种类型（类、结构、枚举、委托等）可以轻松找到正确的文件

回答by Dan

Yes they should, only leads to confusion otherwise.

是的，他们应该这样做，否则只会导致混乱。

回答by Ishmaeel

I'd say yes.

我会说是的。

First, it will be easier to find the actual code files by following down the namespaces (say, when somebody e-mails you a naked exception call stack). If you let your folders go out of sync with namespaces, finding files in big codebases becomes getting tiring.

首先，通过跟踪命名空间（例如，当有人通过电子邮件向您发送裸异常调用堆栈时）会更容易找到实际的代码文件。如果您让文件夹与命名空间不同步，则在大型代码库中查找文件会变得很累。

Second, VS will generate new classes you create in folders with the same namespace of its parent folder structure. If you decide to swim against this, it will be just one more plumbing job to do daily when adding new files.

其次，VS 将生成您在其父文件夹结构具有相同命名空间的文件夹中创建的新类。如果您决定反对这一点，那么在添加新文件时每天要做的只是一项额外的工作。

Of course, this goes without saying that one should be conservative about how deep xis folder/namespace hierarchy goes.

当然，这不言而喻，人们应该对 xis 文件夹/命名空间层次结构的深度持保守态度。

回答by Karl Seguin

I think the standard, within .NET, is to try to do it when possible, but not to create unnecessarily deep structures just to adhere to it as a hard rule. None of my projects follow the namespace == structure rule 100% of the time, sometimes its just cleaner/better to break out from such rules.

我认为 .NET 中的标准是在可能的情况下尝试这样做，而不是创建不必要的深层结构，只是为了遵守它作为硬性规则。我的项目都没有 100% 的时间遵循命名空间 == 结构规则，有时它只是更清晰/更好地打破这些规则。

In Java you don't have a choice. I'd call that a classic case of what works in theory vs what works in practice.

在 Java 中，您别无选择。我将其称为理论可行与实践可行的经典案例。

回答by Jay Bazuzi

@lassevk: I agree with these rules, and have one more to add.

@lassevk：我同意这些规则，还有一点要补充。

When I have nested classes, I still split them out, one per file. Like this:

当我嵌套类时，我仍然将它们分开，每个文件一个。像这样：

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

and

和

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

回答by Weyland Yutani

No.

不。

I've tried both methods on small and large projects, both with single (me) and a team of developers.

我已经在小型和大型项目中尝试过这两种方法，包括单个（我）和一个开发团队。

I found the simplest and most productive route was to have a single namespace per project and all classes go into that namespace. You are then free to put the class files into whatever project folders you want. There is no messing about adding using statements at the top of files all the time as there is just a single namespace.

我发现最简单和最高效的方法是每个项目有一个命名空间，所有类都进入该命名空间。然后您可以自由地将类文件放入您想要的任何项目文件夹中。在文件顶部添加 using 语句并没有什么混乱，因为只有一个命名空间。

It is important to organize source files into folders and in my opinion that's all folders should be used for. Requiring that these folders also map to namespaces is unnecessary, creates more work, and I found was actually harmful to organization because the added burden encourages disorganization.

将源文件组织到文件夹中很重要，我认为应该使用所有文件夹。要求这些文件夹也映射到命名空间是不必要的，会产生更多的工作，而且我发现实际上对组织有害，因为增加的负担会鼓励混乱。

Take this FxCop warning for example:

以这个 FxCop 警告为例：

CA1020: Avoid namespaces with few types
cause: A namespace other than the global namespace contains fewer than five types https://msdn.microsoft.com/en-gb/library/ms182130.aspx

CA1020：避免使用类型
较少的命名空间原因：全局命名空间以外的命名空间包含少于五种类型 https://msdn.microsoft.com/en-gb/library/ms182130.aspx

This warning encourages the dumping of new files into a generic Project.General folder, or even the project root until you have four similar classes to justify creating a new folder. Will that ever happen?

此警告鼓励将新文件转储到通用 Project.General 文件夹中，甚至是项目根目录中，直到您有四个类似的类来证明创建新文件夹是合理的。那会发生吗？

Finding Files

查找文件

The accepted answer says "The classes will be easier to find and that alone should be reasons good enough."

公认的答案是“这些课程将更容易找到，仅此而已就足以成为理由。”

I suspect the answer is referring to having multiple namespaces in a project which don't map to the folder structure, rather than what I am suggesting which is a project with a single namespace.

我怀疑答案是指在一个项目中具有多个命名空间，而这些命名空间不映射到文件夹结构，而不是我建议的具有单个命名空间的项目。

In any case while you can't determine which folder a class file is in from the namespace, you can find it by using Go To Definition or the search solution explorer box in Visual Studio. Also this isn't really a big issue in my opinion. I don't expend even 0.1% of my development time on the problem of finding files to justify optimizing it.

在任何情况下，虽然您无法从命名空间中确定类文件位于哪个文件夹中，但您可以使用转到定义或 Visual Studio 中的搜索解决方案资源管理器框找到它。在我看来，这也不是什么大问题。我什至没有将 0.1% 的开发时间花在寻找文件来证明优化它的问题上。

Name clashes

名称冲突

Sure creating multiple namespaces allows project to have two classes with the same name. But is that really a good thing? Is it perhaps easier to just disallow that from being possible? Allowing two classes with the same name creates a more complex situation where 90% of the time things work a certain way and then suddenly you find you have a special case. Say you have two Rectangle classes defined in separate namespaces:

当然创建多个命名空间允许项目有两个同名的类。但这真的是好事吗？只是不允许这样做可能更容易吗？允许两个具有相同名称的类会造成更复杂的情况，在这种情况下，90% 的时间事情都以某种方式工作，然后您突然发现有一个特殊情况。假设您在不同的命名空间中定义了两个 Rectangle 类：

• class Project1.Image.Rectangle
• class Project1.Window.Rectangle

• 类 Project1.Image.Rectangle
• 类 Project1.Window.Rectangle

It's possible to hit an issue that a source file needs to include both namespaces. Now you have to write out the full namespace everywhere in that file:

可能会遇到源文件需要包含两个命名空间的问题。现在您必须在该文件中的任何地方写出完整的命名空间：

var rectangle = new Project1.Window.Rectangle();

Or mess about with some nasty using statement:

或者弄乱一些讨厌的 using 语句：

using Rectangle = Project1.Window.Rectangle;

With a single namespace in your project you are forced to come up with different, and I'd argue more descriptive, names like this:

在您的项目中使用单个命名空间时，您被迫想出不同的名称，我认为更具描述性的名称如下：

• class Project1.ImageRectangle
• class Project1.WindowRectangle

• 类 Project1.ImageRectangle
• 类 Project1.WindowRectangle

And usage is the same everywhere, you don't have to deal with a special case when a file uses both types.

并且用法在任何地方都相同，当文件同时使用这两种类型时，您不必处理特殊情况。

using statements

使用语句

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

vs

对比

using Project1;

The ease of not having to add namespaces all the time while writing code. It's not the time it takes really, it's the break in flow of having to do it and just filling up files with lots of using statements - for what? Is it worth it?

在编写代码时不必一直添加命名空间的便利。这不是真正需要的时间，而是必须这样做并且只是用大量 using 语句填充文件的流程中断 - 为了什么？这值得么？

Changing project folder structure

更改项目文件夹结构

If folders are mapped to namespaces then the project folder path is effectively hard-coded into each source file. This means any rename or move of a file or folder in the project requires actual file contents to change. Both the namespace declaration of files in that folder and using statements in a whole bunch of other files that reference classes in that folder. While the changes themselves are trivial with tooling, it usually results in a large commit consisting of many files whose classes haven't even changed.

如果文件夹映射到命名空间，则项目文件夹路径被有效地硬编码到每个源文件中。这意味着项目中文件或文件夹的任何重命名或移动都需要更改实际文件内容。该文件夹中文件的命名空间声明和引用该文件夹中类的一大堆其他文件中的 using 语句。虽然更改本身对于工具来说是微不足道的，但它通常会导致大量提交，其中包含许多类甚至没有更改的文件。

With a single namespace in the project you can change project folder structure however you want without any source files themselves being modified.

使用项目中的单个命名空间，您可以随意更改项目文件夹结构，而无需修改任何源文件本身。

Visual Studio automatically maps the namespace of a new file to the project folder it's created in

Visual Studio 自动将新文件的命名空间映射到它在其中创建的项目文件夹

Unfortunate, but I find the hassle of correcting the namespace is less than the hassle of dealing with them. Also I've got into the habit of copy pasting an existing file rather than using Add->New.

不幸的是，我发现纠正命名空间的麻烦比处理它们的麻烦要少。我也养成了复制粘贴现有文件而不是使用 Add->New 的习惯。

Intellisense and Object Browser

智能感知和对象浏览器

The biggest benefit in my opinion of using multiple namespaces in large projects is having extra organization when viewing classes in any tooling that displays classes in a namespaces hierarchy. Even documentation. Obviously having just one namespace in the project results in all classes being displayed in a single list rather than broken into categories. However personally I've never been stumped or delayed because of a lack of this so I don't find it a big enough benefit to justify multiple namespaces.

在我看来，在大型项目中使用多个命名空间的最大好处是，在任何在命名空间层次结构中显示类的工具中查看类时，可以有额外的组织。甚至文档。显然，项目中只有一个命名空间会导致所有类都显示在一个列表中，而不是分成多个类别。然而，就我个人而言，我从来没有因为缺乏这一点而被难倒或延迟，所以我认为它没有足够大的好处来证明多个命名空间的合理性。

Although if I were writing a large public class library then I wouldprobably use multiple namespaces in the project so that the assembly looked neat in the tooling and documentation.

尽管如果我正在编写一个大型公共类库，那么我可能会在项目中使用多个命名空间，以便程序集在工具和文档中看起来很整洁。

回答by user1451111

What's the standard?

标准是什么？

There is no official standard but conventionally the folder-to-namespace mapping pattern is most widely used.

没有官方标准，但通常使用最广泛的是文件夹到命名空间的映射模式。

In class libraries do the folders usually match the namespace structure or is it a mixed bag?

在类库中，文件夹通常与命名空间结构匹配还是混合包？

Yes, in most class libraries the folders match the namespace for organizational ease.

是的，在大多数类库中，为了便于组织，文件夹与命名空间相匹配。