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

c++ namespace usage and naming rules

提问by Mykola Golubyev

On the project we are trying to reach an agreement on the namespace usage. We decided that the first level will be "productName" and the second is "moduleName".

在这个项目中，我们试图就命名空间的使用达成一致。我们决定第一层是“productName”，第二层是“moduleName”。

productName::moduleName

Now if the module is kind of utility module there is no problem to add third namespace. For example to add "str": productName::utilityModuleName::str - to divide space where all "strings" related stuff will go.

现在，如果模块是一种实用程序模块，则添加第三个命名空间没有问题。例如添加“str”：productName::utilityModuleName::str - 划分所有与“字符串”相关的东西所在的空间。

If the module is the main business module we have many opportunities and almost no agreement.

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

For example

例如

class productName::mainModuleName::DomainObject

and

和

class productName::mainModuleName::DomainObjectSomethingElseViewForExample

can be both at

可以同时在

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

Why should we create inner not private classes and not namespaces? Why should we create class where all methods are static (except cases when this class is going to be template parameter)?

为什么我们应该创建内部而不是私有类而不是命名空间？为什么我们要创建所有方法都是静态的类（除非此类将成为模板参数的情况）？

Project consist of 1Gb of source code. So, what is the best practice to divide modules on namespaces in the c++?

项目由 1Gb 的源代码组成。那么，在 C++ 中在命名空间上划分模块的最佳实践是什么？

回答by Brian R. Bondy

What namespaces are for:

命名空间的用途：

Namespaces are meant to establish context only so you don't have naming confilcts.

命名空间仅用于建立上下文，因此您没有命名冲突。

General rules:

通用规则：

Specifying too much context is not needed and will cause more inconvenience than it is worth.

不需要指定太多的上下文，并且会造成比其价值更多的不便。

So you want to use your best judgment, but still follow these 2 rules:

所以你想使用你最好的判断，但仍然遵循以下两条规则：

• Don't be too general when using namespaces
• Don't be too specific when using namespaces

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

I would not be so strict about how to use namespace names, and to simply use namespaces based on a related group of code.

我不会对如何使用命名空间名称如此严格，而是简单地使用基于相关代码组的命名空间。

Why namespaces that are too general are not helpful:

为什么过于通用的命名空间没有帮助：

The problem with dividing the namespace starting with the product name, is that you will often have a component of code, or some base library that is common to multiple products.

划分以产品名称开头的命名空间的问题在于，您通常会有一个代码组件，或一些对多个产品通用的基础库。

You also will not be using Product2 namespaces inside Product1, so explicitly specifying it is pointless. If you were including Product2's files inside Product1, then is this naming conversion still useful?

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

Why namespaces that are too specific are not helpful:

为什么太具体的命名空间没有帮助：

When you have namespaces that are too specific, the line between these distinct namespaces start to blur. You start using the namespaces inside each other back and forth. At this time it's better to generalize the common code together under the same namespace.

当您的命名空间过于具体时，这些不同命名空间之间的界限开始变得模糊。您开始来回使用彼此内部的命名空间。这时候最好将通用代码泛化到同一个命名空间下。

Classes with all static vs templates:

具有所有静态与模板的类：

"Why should we create inner not private classes and not namespaces? Why should we create classes where all methods are static"

“为什么我们应该创建内部而不是私有类而不是命名空间？为什么我们应该创建所有方法都是静态的类”

Some differences:

一些差异：

• Namespaces can be implied by using the usingkeyword
• Namespaces can be aliased, classes are types and can be typedef'ed
• Namespaces can be added to; you can add functionality to it at any time and add to it directly
• Classes cannot be added to without making a new derived class
• Namespaces can have forward declarations
• With classes you can have private members and protected members
• Classes can be used with templates

• 命名空间可以通过使用using关键字来暗示
• 命名空间可以是别名，类是类型并且可以被 typedef
• 可以添加命名空间；您可以随时向其添加功能并直接添加到其中
• 不创建新的派生类就不能添加类
• 命名空间可以有前向声明
• 使用类，您可以拥有私有成员和受保护成员
• 类可以与模板一起使用

Exactly how to divide:

具体如何划分：

"Project consist of 1Gb of source code. So, what is the best practice to divide modules on namespaces in the c++?"

“项目由 1Gb 的源代码组成。那么，在 C++ 中的命名空间上划分模块的最佳实践是什么？”

It's too subjective to say exactly how to divide your code without the exact source code. Dividing based on the modules though sounds logical, just not the whole product.

在没有确切源代码的情况下，确切地说出如何划分代码太主观了。基于模块的划分虽然听起来合乎逻辑，但不是整个产品。

回答by Brian Neal

This is all subjective, but I would hesitate to go more than 3 levels deep. It just gets too unwieldy at some point. So unless your code base is very, very large, I would keep it pretty shallow.

这都是主观的，但我会犹豫是否深入超过 3 个级别。它在某些时候变得太笨拙了。因此，除非您的代码库非常非常大，否则我会将其保留得很浅。

We divide our code into subsystems, and have a namespace for each subsystem. Utility things would go into their own namespace if indeed they are reusable across subsystems.

我们将代码划分为子系统，每个子系统都有一个命名空间。如果实用程序确实可以跨子系统重用，它们将进入自己的命名空间。

回答by Brian Neal

It seems to me that you are trying to use namespaces as a design tool. They are not intended for that, they are intended to prevent name clashes. If you don't have the clashes, you don't need the namespaces.

在我看来，您正在尝试使用命名空间作为设计工具。它们不是为此目的，而是为了防止名称冲突。如果没有冲突，则不需要命名空间。

回答by linuxeasy

I divide namespaces depending on its usages:

我根据其用途划分命名空间：

I have a separate namespace, where I have defined all my interfaces (pure virtual classes).

我有一个单独的命名空间，我在其中定义了所有接口（纯虚拟类）。

I have a separate namespace, where I have defined my library classes (like db library, processing library).

我有一个单独的命名空间，我在其中定义了我的库类（如 db 库、处理库）。

And I have a separate namespace, where I have my core business (business logic) objects (like purchase_order, etc).

而且我有一个单独的命名空间，在那里我有我的核心业务（业务逻辑）对象（如购买订单等）。

I guess, its about defining it in a way, that doesn't becomes difficult to handle in the future. So, you can check the difficulties that will surround on your current design.

我想，它是关于以某种方式定义它，将来不会变得难以处理。因此，您可以检查当前设计中会遇到的困难。

And if you think they are fine, you should go with it.

如果你认为他们很好，你应该去。