c ++命名空间用法和命名规则

在项目中,我们试图就名称空间使用达成一致.我们决定第一级是"productName",第二级是"moduleName".

productName::moduleName

现在,如果模块是一种实用程序模块,则添加第三个命名空间没有问题.例如,添加"str":productName :: utilityModuleName :: str - 来划分所有"字符串"相关内容的空间.

如果模块是主要业务模块,我们有很多机会,几乎没有协议.

例如

class productName::mainModuleName::DomainObject

和

class productName::mainModuleName::DomainObjectSomethingElseViewForExample

可以在

namespace productName::mainModuleName::domainObject
class Data
class ViewForExample

我们为什么要创建内部非私有类而不是名称空间？我们为什么要创建所有方法都是静态的类(除非这个类是模板参数的情况除外)？

项目包含1Gb的源代码.那么,在c ++中划分命名空间模块的最佳实践是什么？

什么名称空间用于:

命名空间仅用于建立上下文,因此您没有命名配置.

通用规则:

不需要指定太多的上下文,并且会带来比它更值得的不便.

所以你想要用你最好的判断,但仍然遵循以下两条规则:

使用命名空间时不要太笼统

使用命名空间时不要太具体

关于如何使用命名空间名称,以及简单地使用基于相关代码组的命名空间,我不会那么严格.

为什么过于笼统的命名空间没有帮助:

将命名空间从产品名称开始划分的问题在于,您通常会拥有一个代码组件,或者一些多个产品通用的基本库.

您也不会在Product1中使用Product2名称空间,因此明确指定它是没有意义的.如果您在Product1中包含Product2的文件,那么这个命名转换是否仍然有用？

为什么过于具体的命名空间没有帮助:

当您具有过于特定的名称空间时,这些不同名称空间之间的界限开始变得模糊.您开始来回使用彼此内部的名称空间.此时,最好在同一名称空间下将公共代码一起概括.

包含所有静态vs模板的类:

"我们为什么要创建内部非私有类而不是名称空间？为什么要创建所有方法都是静态的类"

一些差异:

可以使用using关键字隐含命名空间

命名空间可以是别名,类是类型,可以是typedef

命名空间可以添加到; 您可以随时添加功能并直接添加到它

如果不创建新的派生类,则无法添加类

命名空间可以具有前向声明

通过课程,您可以拥有私人会员和受保护的会员

类可以与模板一起使用

究竟如何划分:

"项目由1Gb的源代码组成.那么,在c ++中划分命名空间模块的最佳实践是什么？"

如果在没有确切源代码的情况下如何划分代码,那就太客观了.基于模块划分虽然听起来合乎逻辑,但不是整个产品.

这都是主观的,但我会犹豫超过3级.它在某些方面变得太笨重了.因此,除非你的代码库非常非常大,否则我会保持它很浅.

我们将代码划分为子系统,并为每个子系统分配命名空间.如果确实它们可以跨子系统重用,那么实用程序将进入它们自己的命名空间.