组织不良实践的子命名空间？

Question

将子命名空间用于纯粹的组织目的会被视为不良做法吗？例如:

namespace vehicles
{
    namespace cars
    {
        // Stuff here
    }

    namespace boats
    {
        // More stuff here
    }
}

我可以看到这对大型项目来说会是一个什么问题,因为输入vehicles::cars::function很多东西会很不方便.那么小项目呢？

Answer 1

为什么vehicles::cars::function在小型项目中输入很多东西会不那么不方便？

记住命名空间应该用于什么目的.他们应该避免名字冲突,而不是其他.

如果你发明了这样一个复杂的命名空间结构,我很想把它们放在using namespace ...每个文件的顶部,那么它就会破坏命名空间的目的.

它也没有真正告诉我很多我不知道的.你打算在你的boats命名空间里放什么我不知道的名字就是一艘船？我是否需要在名称空间中的任何内容上澄清"这属于船只"？很可能没有,然后拥有命名空间是没有意义的.

一般情况下,在您发现优势之前,不要问使用任何语言功能有什么问题.每个功能都需要证明自己的合理性.那么你提出的命名空间会解决什么问题呢？

如果它不能解决一个真实的,实际的问题,那么无论如何,这都是一个坏主意.

我一直认为查看不同语言的标准库是有益的.

.NET使用具有长名称的深嵌套命名空间.简单动态数组的全名是System.Collections.Generic.List<T>.

结果,没有人使用命名空间.每个人都只需要using System.Collections.Generic在每个需要使用List的文件的顶部.

因此,当你遇到另一 List堂课时,你会遇到麻烦.你会想要做同样的事情,瞧,你有两个List班级冲突.

C++使用非常扁平的namespcae结构,其中名称空间也有非常短的名称.

C++中的等价类很简单std::vector.因此,人们通常会输入命名空间前缀,因此,当我向项目中添加另一个矢量类时,*它可以正常工作.没有名称冲突,因为我std::想在引用标准库向量时使用前缀.

Answer 2

好吧，就它的价值而言，几年前，我尝试在一个中型项目上使用深度嵌套的名称空间，这绝对是地狱-我花了整整时间写typedef :)在Java中，程序包工作得很好，因为您只需将内容导入每个.java文件的顶部即可，而不会遇到重大问题。在C ++中，这很痛苦，因为在头文件中使用指令/声明是一种不好的做法-结果，您最终要么（a）完全限定了头文件（bleurgh）中的所有内容，要么（b）使用了许多typedef（也有问题）。不酷-我的建议是避免像瘟疫一样，除非您喜欢写以下内容：

centipede::autoseg::hierarchygeneration::ragbuilders::RAGBuilder<...>

那不是一种类型，而是一个句子...