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.
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.
...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...
Do not use 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
Core - Domain - Users - Permissions - Accounts
Would you create
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.
Most of it is common sense and really down to how you would expect to see the namespaces organised if you were a consumer of your own API or framework.
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.
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:
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
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.
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++.
Now that you question the relation between these two hierarchies, I seriously wonder what you would like to represent by the file system hierarchy.
无论如何,这是我真正喜欢的惯例。如果我将类型拆分为文件夹,那么这些类型可能具有某种与文件夹相关的概念分组。因此,这有一定道理,它们的命名空间也很相似。 Java 采用这种方法并通过其包系统强制执行。最大的区别是 VS 只是向您“建议”它,因为语言或 CLR 都没有强制执行它。
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.
我认为命名空间和项目文件夹具有不同的结构确实有充分的理由。如果您正在开发一个库,那么命名空间结构首先应该为 API 的用户服务:它应该符合逻辑且易于掌握。另一方面,文件夹结构的主要目的应该是让API 设计者的生活变得轻松。有些目标确实非常相似,比如结构也应该符合逻辑。但也可能有不同的,例如您可以快速选择相关文件进行工具,或者易于导航。例如,我自己倾向于在达到某个文件阈值时创建新文件夹,否则需要很长时间才能找到我正在查找的文件。但尊重设计师的偏好也意味着严格遵循命名空间——如果这是他们的偏好的话。
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 users of 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.
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.
通常,我们选择将项目中的文件组织到多个文件夹中,因为我或我的团队更容易浏览文件。通常这个文件组织与我们使用的命名空间设计无关。我希望 VS 团队不会将命名空间默认为与文件夹名称相同,或者至少重新提供不将其设置为默认名称的选项。
不要受苦,要么更改新类的模板,要么在创建新文件后更正命名空间。
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#.
Assemblies are a deployment decision. If you look at the .Net framework a given assembly will contain multiple different namespaces.
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).
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.
Don't suffer, either change the template for new classes or correct the namespace after the new file gets created.
I also feel the pain with this 'by default' behaviour in Visual Studio.
Visual Studio also tries to set a namespace/directory match when you put your LinqToSql .dbml files in their own directory. Whenever I edit the .dbml, I have to remember to:
open the .dbml.designer.cs file
remove the directory/folder name from the namespace declaration
There's a way to stop this behaviour, though. It involves creating a custom class template.
虽然我同意将命名空间层次结构与文件夹层次结构相匹配很方便,而且是个好主意,但我认为 Visual Studio 似乎不支持关闭此功能这一事实令人厌恶。 Visual Studio 有很多应用程序,并且有很多编码风格和构建源文件文件夹的方法,这些都非常好。
假设某个命名空间中有数千个文件,但程序员只想将它们分组到文件夹中以使层次结构更易于导航。这真的是一个坏主意吗?这真的会让事情变得如此难以维护以至于应该被 IDE 禁止吗???
假设我正在使用 Visual Studio 来处理 Unity。现在,我的所有脚本都位于“Assets.Scripts”命名空间中。不仅有一个无用的 Assets 命名空间现在不包含任何脚本,而且“Assets.Scripts”也毫无意义——它没有描述源文件属于哪个项目或项目的一部分。无用。
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.
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???
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.
发布评论
评论(10)
和你一样——我为此奋斗了最长的时间。然后我开始考虑为什么要创建文件夹。我发现自己开始创建文件夹来表示名称空间和包,而不是任意存储桶。
例如,在 MVVM 项目中,将视图和视图模型放在单独的命名空间中可能会有所帮助。 MVC 将为模型、控制器和视图提供单独的命名空间。根据班级的特点对班级进行分组也是有益的。
突然间,这个项目感觉更有条理了。其他开发人员可以更轻松地找到功能的实现位置。
如果您对命名空间实践进行标准化,那么所有项目都将具有相同的可预测结构,这对于维护来说将是一个巨大的胜利。
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.
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.
如果您需要一些可靠的建议,我建议购买 框架设计指南:约定、习语和模式可重用的 .NET 库,它为您提供了实际框架设计团队需要了解的所有信息。
而且重要的是
每 1/2 类型分段到命名空间中不会满足第一个要求,因为您将拥有大量必须经过限定的命名空间或使用,如果您遵循 Visual Studio 方式。例如
核心
- 领域
- 用户
- 权限
- 帐户
您会创建
还是只是
对于 Visual Studio 的方式,它会是前者。此外,如果您使用小写文件/文件夹命名,您每次都会考虑重命名该类,并造成一个大的命名空间混乱。
其中大部分都是常识,并且实际上取决于您希望如何组织命名空间(如果您是您自己的 API 或框架的使用者)。
If you want some solid advice I'd recommend buying Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries which gives you all you need to know from the actual framework design team.
And importantly
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
Core
- Domain
- Users
- Permissions
- Accounts
Would you create
or just
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.
Most of it is common sense and really down to how you would expect to see the namespaces organised if you were a consumer of your own API or framework.
我也对此感到恼火,但与大型代码库一起工作和重构项目很快就教会了我其他方面的知识。接受这个概念后,我认为这是一种“物理上”和逻辑上构建代码的好方法。当您有一个大型项目并且名称空间与文件夹不匹配时,快速找到文件就会变得困难。记住东西在哪里也变得更加困难......
此外,如果 ReSharper 推荐它,那么这可能是一个好主意。例如,如果类的命名空间与其文件夹名称不匹配,R# 会抱怨。
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.
虽然我同意其他人的观点,即物理结构与逻辑结构相匹配是有帮助的,但我不得不说我也反对 Visual Studio 的自动命名。我必须重命名类的原因有六个:
出于这些原因,我已经接受了必须为我创建的每个类调整这些接口。我避免此问题的策略是复制具有所需命名空间声明的文件,然后立即删除内容。
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:
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.
文件系统文件夹和命名空间都代表层次结构。对我来说,将两者相匹配是很自然的。我更进一步,在文件和类之间使用 1:1 的关系。我什至在使用其他语言(例如 C++)编程时也会这样做。
既然您质疑这两个层次结构之间的关系,我认真地想知道您想用文件系统层次结构来表示什么。
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++.
Now that you question the relation between these two hierarchies, I seriously wonder what you would like to represent by the file system hierarchy.
不遵循约定的一种方法是在项目根文件夹中创建文件,然后将其移动到最终的子文件夹。
无论如何,这是我真正喜欢的惯例。如果我将类型拆分为文件夹,那么这些类型可能具有某种与文件夹相关的概念分组。因此,这有一定道理,它们的命名空间也很相似。 Java 采用这种方法并通过其包系统强制执行。最大的区别是 VS 只是向您“建议”它,因为语言或 CLR 都没有强制执行它。
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.
我认为命名空间和项目文件夹具有不同的结构确实有充分的理由。如果您正在开发一个库,那么命名空间结构首先应该为 API 的用户服务:它应该符合逻辑且易于掌握。另一方面,文件夹结构的主要目的应该是让API 设计者的生活变得轻松。有些目标确实非常相似,比如结构也应该符合逻辑。但也可能有不同的,例如您可以快速选择相关文件进行工具,或者易于导航。例如,我自己倾向于在达到某个文件阈值时创建新文件夹,否则需要很长时间才能找到我正在查找的文件。但尊重设计师的偏好也意味着严格遵循命名空间——如果这是他们的偏好的话。
总体而言,在许多情况下,两者匹配是有道理的,但我认为存在偏离的有效情况。
过去对我有用的是在一个地方创建一个文件(例如 WPF UserControl)以获得正确的命名空间,然后将其移动到“正确”的文件夹。
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 users of 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.
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.
在 C++ 中引入命名空间之前,所有 C 类型都位于全局命名空间中。创建命名空间是为了将类型分隔到逻辑容器中,因此很清楚所引用的类型。这也适用于 C#。
程序集是一个部署决策。如果您查看 .Net 框架,给定的程序集将包含多个不同的命名空间。
文件夹用于组织磁盘上的文件。
这三者彼此无关,但是,程序集名称、命名空间和文件夹名称相同通常很方便。请注意,Java 将文件夹和名称空间折叠为同一事物(限制了开发人员组织文件和名称空间的自由)。
通常,我们选择将项目中的文件组织到多个文件夹中,因为我或我的团队更容易浏览文件。通常这个文件组织与我们使用的命名空间设计无关。我希望 VS 团队不会将命名空间默认为与文件夹名称相同,或者至少重新提供不将其设置为默认名称的选项。
不要受苦,要么更改新类的模板,要么在创建新文件后更正命名空间。
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#.
Assemblies are a deployment decision. If you look at the .Net framework a given assembly will contain multiple different namespaces.
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).
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.
Don't suffer, either change the template for new classes or correct the namespace after the new file gets created.
我也对 Visual Studio 中的这种“默认”行为感到痛苦。
当您将 LinqToSql
.dbml
文件放入其自己的目录中时,Visual Studio 还会尝试设置命名空间/目录匹配。每当我编辑.dbml
时,我必须记住:.dbml.designer.cs
文件命名空间
中删除目录/文件夹名称code> 声明不过,有一种方法可以停止这种行为。它涉及创建自定义类模板。
I also feel the pain with this 'by default' behaviour in Visual Studio.
Visual Studio also tries to set a namespace/directory match when you put your LinqToSql
.dbml
files in their own directory. Whenever I edit the.dbml
, I have to remember to:.dbml.designer.cs
filenamespace
declarationThere's a way to stop this behaviour, though. It involves creating a custom class template.
虽然我同意将命名空间层次结构与文件夹层次结构相匹配很方便,而且是个好主意,但我认为 Visual Studio 似乎不支持关闭此功能这一事实令人厌恶。 Visual Studio 有很多应用程序,并且有很多编码风格和构建源文件文件夹的方法,这些都非常好。
假设某个命名空间中有数千个文件,但程序员只想将它们分组到文件夹中以使层次结构更易于导航。这真的是一个坏主意吗?这真的会让事情变得如此难以维护以至于应该被 IDE 禁止吗???
假设我正在使用 Visual Studio 来处理 Unity。现在,我的所有脚本都位于“Assets.Scripts”命名空间中。不仅有一个无用的 Assets 命名空间现在不包含任何脚本,而且“Assets.Scripts”也毫无意义——它没有描述源文件属于哪个项目或项目的一部分。无用。
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.
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???
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.