组织不良做法的子命名空间？
将子命名空间用于纯粹的组织目的会被认为是不好的做法吗？例如：
namespace vehicles
{
namespace cars
{
// Stuff here
}
namespace boats
{
// More stuff here
}
}
我可以看到这在大型项目中会成为一个问题，因为大量输入 vehicles::cars::function 会很不方便。那么小项目呢？
Would it be considered bad practice to use sub-namespaces for purely organizational purposes? For example:
namespace vehicles
{
namespace cars
{
// Stuff here
}
namespace boats
{
// More stuff here
}
}
I can see how this would be a problem on large projects, because it would be inconvenient to type vehicles::cars::function a lot. What about small projects, though?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为什么在小项目中大量输入
vehicles::cars::function会不会那么不方便？请记住命名空间的用途。他们应该避免名字冲突，仅此而已。
如果您发明了如此复杂的命名空间结构，以至于我很想在每个文件的顶部放置一些
using namespace ...，那么它就违背了命名空间的目的。它也并没有告诉我太多我不知道的事情。您要在您的
boats命名空间中放入什么，而我仅从名称中无法知道它是一艘船？我是否需要澄清名称空间中的任何内容“这属于船”？很可能不会，那么拥有命名空间就没有意义了。一般来说，在发现使用任何语言功能的优点之前，不要问有什么问题。每个功能都需要证明自己的合理性。那么您提出的名称空间会解决什么问题呢？
如果它不能解决真正的、实际的问题，那么无论其他什么，它都是一个坏主意。
我始终认为查看不同语言的标准库是有启发性的。
.NET 使用具有长名称的深度嵌套命名空间。简单动态数组的全名是
System.Collections.Generic.List。结果，没有人使用该命名空间。每个人只需在每个需要使用 List 的文件的顶部放置一个
using System.Collections.Generic即可。因此，当您遇到另一个
List类时，您就会遇到麻烦。您会想要对此执行相同的操作，瞧，您有两个发生冲突的List类。C++ 使用非常扁平的命名空间结构，其中命名空间也有非常短的名称。
C++ 中的等效类就是
std::vector。因此，人们通常会输入名称空间前缀，因此，当我向项目中添加另一个向量类时，“它可以工作”。不存在名称冲突，因为当我想引用标准库向量时，我使用std::前缀。Why would it be less inconvenient to type
vehicles::cars::functiona lot in a small project?Remember what purpose namespaces are supposed to serve. They are supposed to avoid name clashes, and not much else.
If you invent such a convoluted namespace structure that I'm tempted to just put a few
using namespace ...'s at the top of every file, then it defeats the purpose of namespaces.It also doesn't really tell me much I didn't know already. What are you going to put in your
boatsnamespace that I wouldn't know from the name alone was a boat? Am I going to need the clarification that "this belongs with the boats" on anything in the namespace? Most likely not, and then there's no point in having the namespace.In general, don't ask what problems there are with using any language feature until you've found out what the advantages are. Every feature needs to justify itself. So what problem would your proposed namespaces solve?
If it wouldn't solve a real, actual problem, then it is a bad idea, regardless of anything else.
I always think it's instructive to look at different language's standard libraries.
.NET uses deeply nested namespaces with long names. The full name for a simple dynamic array is
System.Collections.Generic.List<T>.As a result, no-one ever uses the namespace. Everyone just puts a
using System.Collections.Genericat the top of every file that needs to use a List.And because of this, you're in trouble the moment you encounter another
Listclass. You'll want to do the same with that, and voila, you have twoListclasses clashing.C++ uses a very flat namespcae structure, where namespaces also have very short names.
The equivalent class in C++ is simply
std::vector. As a result, people generally type out the namespace prefix, and so, when I add another vector class to my project, *it works'. There are no name clashes, because I use thestd::prefix when I want to refer to the standard library vector.好吧，不管怎样，几年前我尝试在一个中型项目上使用深度嵌套的命名空间，这绝对是地狱——我把全部时间都花在了编写 typedef 上:) 在 Java 中，包工作得很好，因为您可以只在每个 .java 文件的顶部导入内容，而不会出现重大问题。在 C++ 中，这是一个痛苦的事情，因为将 using 指令/声明放在头文件中是不好的做法 - 结果，您最终要么 (a) 完全限定头文件中的所有内容 (bleurgh) 或 (b) 使用很多 typedef（也是 bleurgh）。不酷——我的建议是像瘟疫一样避免，除非你喜欢写这样的东西：
这不是一种类型，这是一个句子......
Well, for what it's worth, I tried using deeply-nested namespaces on a medium-sized project a couple of years back, and it was absolute hell -- I spent my entire time writing typedefs :) In Java, packages work quite nicely, because you can just import things at the top of each .java file and not have major problems. In C++, it's a pain in the butt, because it's bad practice to put using directives/declarations in header files -- as a result, you end up either (a) fully-qualifying everything in headers (bleurgh) or (b) using lots of typedefs (also bleurgh). Not cool -- my advice would be to avoid like the plague, unless you enjoy writing things like:
That's not a type, it's a sentence...
恕我直言，这不是坏习惯！还可以考虑使用别名来避免每次都键入完全限定名称，而不是在需要时注入整个命名空间...
IMHO it's not bad practice! Also consider using aliases to get around having to type the fully qualified name every time and not injecting the whole namespace where needed...
命名空间的原因之一是出于组织目的，它们的细粒度取决于个人喜好 - 我个人将它们保持相当通用，例如我有 TransferObjects。车辆，但没有比这更细粒度的了。除非你有很多很多类型，否则我认为没有必要讨论那么多细节。但这取决于你。
如果它是一个小项目，那么代码库应该相对较小并且易于导航，从而消除对这种方法的需要吗？
One of the reasons for Namespaces are for organisational purposes, how finely grained you make them is up to personal preference - I keep them fairly generic personally, for example I'd have TransferObjects. Vehicles, but not go any finely grained than that. Unless you have many many types, I don't see a point in going into that much detail. But that is up to you.
If it's a small project, then should the code base be relatively small and easily navigable, thus removing the need for such an approach?