c++ namespace usage and naming rules

Question

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

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.

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++?

Answer 1

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?

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 using keyword
• 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

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++?"

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.

Answer 2

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.

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.

Answer 3

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.

Answer 4

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).

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.