我正在编写一个包含大量类的C ++程序。在我的脑海中，我可以将它们视为不同的集合。例如，有一组用于读取和存储配置数据的类，另一个用于绘制具有各种小部件的用户界面的集合。
这些集合中的每一个都可以整齐地存储在不同的名称空间中，这看起来很合理。配置部分具有“屏幕”类，并且GUI部分也具有“屏幕”类，但它们彼此不同。我可以重命名一个“gui_screen”和另一个“config_screen”，但这就是命名空间的重点不是吗？为了删除这些前缀，我们发明要分开的东西。
然后我认为将这些命名空间存储在一个主要命名空间中是很整洁的，这样我的代码就不会干扰任何其他命名空间。我想它也可能使代码更具可读性。
或者我只是毫无理由地制作过于复杂的数据层次结构？
答案 0 :(得分：6)
如果你的命名空间有“gui”和“config”等常用名称，那么你的代码可能在将来成为一个库的一部分，意味着与你不受你控制的其他代码相关联，将所有“你的”命名空间嵌套到一个命名的命名空间（可能没有其他内容除了嵌套命名空间）之前确实可能是一个好主意，它们将它们标识为“你的”。这样做确实没有任何惩罚，特别是如果您认为可以以有助于提高可读性的方式完成。 （这与类继承的深层嵌套层次结构完全不同，这肯定会妨碍清晰度，因为每层都添加了不同的功能，并且代码的读者或维护者必须在许多文件中跳转到看到或改变添加的内容！ - ）
答案 1 :(得分：4)
不，IMO你根本没有太过分。
并抵制使用using声明或（天堂禁止！）using指令的诱惑！总是输入所有命名空间需要很少的习惯，一旦习惯了它，它使代码更容易阅读和理解。 （“screen或gui再次出现config类型？”）
答案 2 :(得分：3)
就我个人而言，我从未见过两个以上级别的命名空间嵌套，它们都是有意义或有用的。你所描述的听起来不错，但我不会比project :: component更深入，除非你有一个有形的，可证明的，“这没有它的理由”这样做的理由。换句话说，foo::bar::screen是合理的，foo::bar::ui::screen是非常值得怀疑的，而且除此之外的任何东西几乎肯定会引入比合理的复杂性更多的复杂性。
答案 3 :(得分：2)
这不是矫枉过正。嵌套命名空间是合理的，例如piku::gui::screen等。
您也可以将它们折叠为piku_gui_screen，但是使用单独的嵌套命名空间，您可以获得以下优势：如果您位于piku::gui内，则可以轻松访问该命名空间中的所有名称（例如screen会自动解析为piku::gui::screen。
答案 4 :(得分：0)
定义你没有做任何层次结构的命名空间，所以我看不出问题是什么，无论如何命名空间只是为了解决你的问题。
答案 5 :(得分：0)
我个人喜欢按功能分组文件/类。我通常从一个名称与我将使用的名称空间匹配的文件夹开始。最终，如果名称空间需要在另一个应用程序中重用，您可以轻松地将其取出并将其构建到自己的dll中并共享它。
它还有一个很好的intellisense，所以当我深入查看命名空间时，我只能看到属于该组功能的类。
答案 6 :(得分：0)
在我看来，每个开发人员应该有一个命名空间 - 你（大概）可以控制你在自己的代码中定义的所有类型名称，并且你不太可能想要使用相同的类型名称适用于同一项目中的不同类型。
我认为名称空间的主要用途是处理两个独立开发人员碰巧选择相同类型名称的情况 - 没有名称空间，你无法在同一个项目中使用两个开发人员的代码。单个开发人员代码库中的多个名称空间OTOH只会增加复杂性和打字开销，几乎没有补偿效益。
当然，所有恕我直言。