C# 我应该停止反对 Visual Studio 的默认命名空间命名约定吗？

Should I stop fighting Visual Studio's default namespace naming convention?

提问by devuxer

I'm working on an MVVM project, so I have folders in my project like Models, ViewModels, Windows, etc. Whenever I create a new class, Visual Studio automatically adds the folder name to the namespace designation instead of just keeping the project-level namespace. So, adding a new class to the ViewModels folder would result in the namespace, MyProject.ViewModelsinstead of just MyProject.

我正在处理一个 MVVM 项目，所以我的项目中有文件夹，如模型、视图模型、Windows 等。每当我创建一个新类时，Visual Studio 会自动将文件夹名称添加到命名空间指定中，而不仅仅是保留项目 -级别命名空间。因此，将新类添加到 ViewModels 文件夹将导致命名空间，MyProject.ViewModels而不仅仅是MyProject.

When I first encountered this, it annoyed me. My class names are pretty clear, sometimes even containing the name of the folder in them (e.g., ContactViewModel). I quickly found myself manually removing the folder name on the namespaces. I even tried at one point to create a custom class template (see this question), but I couldn't get that to work, so continued doing it manually.

当我第一次遇到这种情况时，它让我很恼火。我的班级名称非常清楚，有时甚至包含其中的文件夹名称（例如，ContactViewModel）。我很快发现自己手动删除了命名空间上的文件夹名称。我什至一度尝试创建自定义类模板（请参阅此问题），但我无法使其正常工作，因此继续手动执行此操作。

I've begun to wonder, though, if this convention exists for a good reason that I'm just not seeing. I could see it being useful if you for some reason had lots of sets of identical class names organized into folders, but that doesn't seem like a particularly common scenario.

不过，我已经开始怀疑，这个约定的存在是否有一个我没有看到的充分理由。如果您出于某种原因将大量相同的类名组织到文件夹中，我可以看到它很有用，但这似乎不是一个特别常见的场景。

Questions:

问题：

• Why is it common convention for namespace names to reflect folder structure?
• Do you abide by this convention? Why?

• 为什么命名空间名称是反映文件夹结构的常见约定？
• 你遵守这个约定吗？为什么？

采纳答案by Jordan Parmer

Same as you - I fought this for the longest time. Then I started considering why I created folders. I found myself starting to create folders to represent namespaces and packages instead of arbitrary buckets.

和你一样 - 我打了最长时间。然后我开始考虑为什么要创建文件夹。我发现自己开始创建文件夹来表示命名空间和包，而不是任意存储桶。

For instance, in an MVVM project, it might be helpful to put views and view models in a separate namespace. MVC will have a separate namespace for Models, Controllers, and Views. It is also beneficial to group classes by their feature.

例如，在 MVVM 项目中，将视图和视图模型放在单独的命名空间中可能会有所帮助。MVC 将为模型、控制器和视图提供单独的命名空间。按类的功能对类进行分组也有好处。

Suddenly, the project feels more organized. It is easier for other developers to find where features are implemented.

突然间，这个项目感觉更有条理了。其他开发人员更容易找到实现功能的位置。

If you standardize on your namespace practices, all of your projects will have the same predictable structure which will be a big win for maintenance.

如果您标准化您的命名空间实践，您的所有项目都将具有相同的可预测结构，这将是维护的一大胜利。

回答by p.campbell

I also feel the pain with this 'by default' behaviour in Visual Studio.

我也感受到 Visual Studio 中这种“默认”行为的痛苦。

Visual Studio also tries to set a namespace/directory match when you put your LinqToSql .dbmlfiles in their own directory. Whenever I edit the .dbml, I have to remember to:

当您将 LinqToSql.dbml文件放在它们自己的目录中时，Visual Studio 还会尝试设置命名空间/目录匹配。每当我编辑 时.dbml，我必须记住：

• open the .dbml.designer.csfile
• remove the directory/folder name from the namespacedeclaration

• 打开.dbml.designer.cs文件
• 从namespace声明中删除目录/文件夹名称

There's a way to stop this behaviour, though. It involves creating a custom class template.

不过，有一种方法可以阻止这种行为。它涉及创建自定义类模板。

回答by Rui Craveiro

One way of not following the convention is to create the file in the project root folder and then move it to the final sub-folder.

不遵循约定的一种方法是在项目根文件夹中创建文件，然后将其移动到最终的子文件夹中。

Anyhow, it is a convention I actually like. If I am splitting types into folders, then probably those types have some kind of conceptual grouping related to the folder. Therefore, it ends making some sense, their namespaces are also similar. Java takes this approach and enforces it with its package system. The biggest difference is that VS is only "suggesting" it to you, since neither the language or the CLR enforces it.

无论如何，这是我真正喜欢的约定。如果我将类型拆分为文件夹，那么这些类型可能具有某种与文件夹相关的概念分组。因此，它结束是有道理的，它们的命名空间也相似。Java 采用这种方法并通过它的包系统强制执行它。最大的区别是 VS 只是向您“建议”它，因为语言或 CLR 都没有强制执行它。

回答by Malte Clasen

File system folders and namespaces both represent a hierarchy. I seems perfectly natural to me to match the two. I go even one step further and use a 1:1 relationship between files and classes. I even do so when I program in other languages such as C++.

文件系统文件夹和命名空间都代表一个层次结构。对我来说，将两者匹配起来似乎很自然。我更进一步，在文件和类之间使用 1:1 的关系。我什至在用 C++ 等其他语言编程时也会这样做。

Now that you question the relation between these two hierarchies, I seriously wonder what you would like to represent by the file system hierarchy.

既然您质疑这两个层次结构之间的关系，我很想知道您想用文件系统层次结构表示什么。

回答by Paul Sasik

i was annoyed by this as well but working with and refactoring projects with large codebases quickly taught me otherwise. Having embraced the concept i think that it's a very good way to structure your code "physically" as well as logically. When you have a large project and the namespaces do not match up to the folders it becomes difficult to locate files quickly. It's also that much more difficult to remember where things are...

我也对此感到恼火，但使用和重构具有大型代码库的项目很快就教会了我其他方面。接受了这个概念后，我认为这是一种在“物理”和逻辑上构建代码的好方法。当您有一个大型项目并且命名空间与文件夹不匹配时，很难快速定位文件。记住东西在哪里也更加困难......

Also, if ReSharper recommends it, then it's probably a good idea. E.g. R# will complain if your class' namespace does not match its folder name.

此外，如果 ReSharper 推荐它，那么这可能是一个好主意。例如，如果您的类的命名空间与其文件夹名称不匹配，R# 会抱怨。

回答by Chris S

If you want some solid advice I'd recommend buying Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Librarieswhich gives you all you need to know from the actual framework design team.

如果您想要一些可靠的建议，我建议您购买Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries，它为您提供了您需要从实际框架设计团队那里了解的所有信息。

...the goal when naming namespaces is creating sufficient clarity for the programmer using the framework to immediately know what the content of the namespace is likely to be...

...命名命名空间的目标是为使用框架的程序员创造足够的清晰度，以便立即知道命名空间的内容可能是什么...

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

And importantly

而且重要的是

Do notuse the same name for a namespace and a type in that namespace

不要对命名空间和该命名空间中的类型使用相同的名称

Fragmenting every 1/2 types into namespaces would not meet the first requirement as you would have a swamp of namespaces that would have to be qualified or used, if you followed the Visual Studio way. For example

将每 1/2 种类型分成命名空间将无法满足第一个要求，因为如果您遵循 Visual Studio 的方式，您将拥有大量必须限定或使用的命名空间。例如

Core - Domain - Users - Permissions - Accounts

核心 - 域 - 用户 - 权限 - 账户

Would you create

你会创造

• MyCompany.Core.Domain.Users
• MyCompany.Core.Domain.Permissions
• MyCompany.Core.Domain.Accounts

• MyCompany.Core.Domain.Users
• MyCompany.Core.Domain.Permissions
• MyCompany.Core.Domain.Accounts

or just

要不就

• MyCompany.Core.Domain

• 我的公司.核心.域

For Visual Studio's way it would be the former. Also if you use lowercase file/folder naming you're looking at renaming the class each time, as well as making one big namespace tangle.

对于 Visual Studio 的方式，它将是前者。此外，如果您使用小写的文件/文件夹命名，您每次都在考虑重命名类，以及使一个大的命名空间混乱。

Most of it is common sense and really down to how you would expect to see the namespaces organised if youwere a consumer of your own API or framework.

其中大部分是常识，实际上取决于如果您是自己的 API 或框架的使用者，您希望如何组织命名空间。

回答by Hounshell

While I agree with everyone else, that a physical structure matching the logical structure is helpful, I have to say I also fight with Visual Studio's auto-naming. There are half a dozen reasons why I have to rename classes:

虽然我同意其他人的观点，即匹配逻辑结构的物理结构是有帮助的，但我不得不说我也与 Visual Studio 的自动命名作斗争。我必须重命名类的原因有六个：

• I use a root "src" folder to visually separate my code from embedded resources
• I want different capitalization
• I'll organize my code into subfolders for organization within a namespace
• I like to separate interfaces from implementations and base classes
• I feel like it

• 我使用根“src”文件夹在视觉上将我的代码与嵌入的资源分开
• 我想要不同的大小写
• 我会将我的代码组织到子文件夹中，以便在命名空间内进行组织
• 我喜欢将接口与实现和基类分开
• 我觉得像

With thiose reasons, I've resigned myself to having to adjust those for every class I create. My strategy to avoid the issue is copying a file that has the namespace declaration I want, and then immediately delete the contents.

出于种种原因，我已经让自己不得不为我创建的每个类调整这些。我避免这个问题的策略是复制一个具有我想要的命名空间声明的文件，然后立即删除内容。

回答by Franklin Wise

Before namespaces were introduced in C++ all C types were in the global namespace. Namespaces were created to segregate types into logical containers so it was clear what type is being referred to. This also applies to C#.

在 C++ 中引入命名空间之前，所有 C 类型都在全局命名空间中。创建命名空间是为了将类型隔离到逻辑容器中，因此很清楚所引用的类型。这也适用于 C#。

Assemblies are a deployment decision. If you look at the .Net framework a given assembly will contain multiple different namespaces.

程序集是部署决策。如果您查看 .Net 框架，则给定的程序集将包含多个不同的命名空间。

Folder are to organize files on disk.

文件夹用于组织磁盘上的文件。

The three have nothing to do with each other, however, it's often convenient that the assembly name, namespace and folder names are the same. Note that Java collapses folders and namespaces to be the same thing (limiting the developer's freedom to organize files and namespaces).

这三者彼此无关，但是，程序集名称、命名空间和文件夹名称相同通常很方便。请注意，Java 将文件夹和命名空间折叠为同一件事（限制了开发人员组织文件和命名空间的自由）。

Often we choose to organize files in a project into multiple folders because it's easier for me or my team to navigate the files. Usually this file organization has nothing to do with the namespace design we use. I wish the VS team would not default the namespace to be the same as the folder name or at least give the option back to not have this be the default.

我们通常选择将项目中的文件组织到多个文件夹中，因为我或我的团队可以更轻松地浏览文件。通常这种文件组织与我们使用的命名空间设计无关。我希望 VS 团队不会将命名空间默认为与文件夹名称相同，或者至少将选项返回给不将其设为默认值。

Don't suffer, either change the template for new classes or correct the namespace after the new file gets created.

不要受苦，要么更改新类的模板，要么在创建新文件后更正命名空间。

回答by Sava B.

While I agree that matching the namespace hierarchy to the folder hierarchy is handy, and a good idea, I think the fact that Visual Studio doesn't seem to support switching this feature off is disgusting. Visual Studio has a lot of applications, and there are plenty of coding styles and ways of structuring the source file folders that are perfectly fine.

虽然我同意将命名空间层次结构与文件夹层次结构进行匹配很方便，而且是一个好主意，但我认为 Visual Studio 似乎不支持关闭此功能的事实令人作呕。Visual Studio 有很多应用程序，并且有很多编码风格和构建源文件夹的方法非常好。

Let's say there's thousands of files that belong in a namespace, but the programmer just wants to group them into folders to make the hierarchy easier to navigate. Is this really such a bad idea? Will this really make things so un-maintainable that it should be forbidden by the IDE???

假设有数以千计的文件属于命名空间，但程序员只是想将它们分组到文件夹中，以使层次结构更易于导航。这真的是个坏主意吗？这真的会使事情变得不可维护，以至于 IDE 应该禁止它吗？？？

Let's say I'm using Visual Studio to work with Unity. Now, all my scripts are in the "Assets.Scripts" namespace. Not only is there a useless Assets namespace which contains no scripts now, but "Assets.Scripts" is meaningless - it does not describe what project or part of project the source file belongs to. Useless.

假设我使用 Visual Studio 来处理 Unity。现在，我所有的脚本都在“Assets.Scripts”命名空间中。现在不仅有一个无用的 Assets 命名空间，它不包含任何脚本，而且“Assets.Scripts”毫无意义——它没有描述源文件属于哪个项目或项目的一部分。无用。

回答by micTronic

I think there are indeed valid reasons for having different structures for namespaces and project folders. If you are developing a library, the namespace structure should first and foremost serve the usersof your API: it should be logical and easy to grasp. On the other hand, the folder structure should be primarily there to make life easy for you, the API designer. Some goals are indeed very similar, like that the structure should be logical, too. But there may also be different ones, e.g. that you can quickly select related files for tooling, or that it is easy to navigate. I myself for example tend to create new folders when a certain file threshold is reached, otherwise it just takes too long to locate the file I'm looking for. But respecting the designer's preference can also mean strictly following the namespace - if that is their preference.

我认为命名空间和项目文件夹具有不同的结构确实有正当理由。如果你正在开发一个库，命名空间结构首先应该为你的 API用户服务：它应该是合乎逻辑的并且易于掌握。另一方面，文件夹结构应该主要是为了让API 设计者的生活更轻松. 有些目标确实非常相似，比如结构也应该合乎逻辑。但也可能存在不同的情况，例如，您可以快速选择相关文件用于工具，或者易于导航。例如，当达到某个文件阈值时，我自己倾向于创建新文件夹，否则定位我要查找的文件所需的时间太长。但是尊重设计师的偏好也意味着严格遵循命名空间——如果这是他们的偏好的话。

So overall, in many cases it makes sense that both match, but I think there are valid cases to deviate.

所以总的来说，在很多情况下，两者匹配是有道理的，但我认为有一些有效的情况可以偏离。

What has been helpful in the past for me was creating a file (e.g. WPF UserControl) in one place to get the namespace right and then moving it to the "right" folder.

过去对我有用的是在一个地方创建一个文件（例如 WPF UserControl）以获得正确的命名空间，然后将其移动到“正确”文件夹。