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

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

我同意。

首先，通过跟踪名称空间(比如，当有人给您发电子邮件发送一个裸异常调用堆栈时) ，可以更容易地找到实际的代码文件。如果您让您的文件夹与名称空间不同步，那么在大代码库中查找文件就会变得很累。

其次，VS 将生成在与其父文件夹结构具有相同命名空间的文件夹中创建的新类。如果您决定游泳反对这一点，它将只是一个管道工作，做每天添加新的文件。

当然，不言而喻，对于 xis 文件夹/名称空间层次结构的深度应该保守。

我认为标准，在。NET，就是尽可能做到这一点，而不是创建不必要的深层结构，只是坚持它作为一个硬规则。我的项目中没有一个是100% 遵循名称空间 = = 结构规则的，有时候打破这样的规则会更干净/更好。

在爪哇，你别无选择。我认为这是一个典型的例子，说明什么在理论上行得通，什么在实践中行得通。

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

类将更容易找到，这本身就应该是足够好的理由。

我们遵循的规则是:

• 项目/程序集名称与根命名空间相同，但. dll 结尾除外
• 上述规则的唯一例外是一个以.Core 结尾的项目，去掉了.Core
• 文件夹等于名称空间
• 每个文件一个类型(类、结构、枚举、委托等)可以很容易地找到正确的文件

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

当我有嵌套类时，我仍然将它们分离出来，每个文件一个:

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

还有

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

没有。

我在小型和大型项目中都尝试过这两种方法，包括单人(我)和一个开发人员团队。

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

将源文件组织到文件夹中是很重要的，在我看来，所有的文件夹都应该用于这个目的。要求这些文件夹也映射到名称空间是不必要的，这会造成更多的工作，而且我发现这实际上对组织是有害的，因为增加的负担会鼓励混乱。

以 FxCop 的警告为例:

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

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

寻找文件

公认的答案是: “这些课程更容易找到，这本身就应该是足够好的理由。”

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

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

名字冲突

当然，创建多个名称空间允许项目拥有两个具有相同名称的类。但这真的是好事吗？否认这种可能性会更容易些吗？允许两个具有相同名称的类创建了一个更复杂的情况，其中90% 的情况下事情按照特定的方式工作，然后突然您发现您有一个特殊的情况。假设您有两个矩形类，它们分别定义在不同的命名空间中:

• 类 Project1.Image. 矩形
• 类 Project1.Window. 矩形

可能会遇到源文件需要同时包含两个名称空间的问题。现在，您必须在该文件中写出所有地方的完整名称空间:

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

或者乱用一些下流的用法:

using Rectangle = Project1.Window.Rectangle;

对于项目中的单个名称空间，您必须提出不同的名称，我认为更具描述性的名称如下:

• 类 Project1.ImageRecangle
• 类 Project1.Windows 矩形

而且用法在任何地方都是一样的，当一个文件同时使用这两种类型时，您不必处理特殊情况。

使用语句

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

对

using Project1;

在编写代码时不必一直添加名称空间的简便性。这并不是真正花费的时间，而是不得不这样做的流程的中断，只是用大量的使用语句来填充文件——为了什么？值得吗？

更改项目文件夹结构

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

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

VisualStudio 会自动将新文件的命名空间映射到在 中创建的项目文件夹

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

智能感知和对象浏览器