Consistent approach for renaming namespaces in C++

Question

When using nested namespaces sometimes fully qualified names end up being quite long. I know I can use namespace abc = aaa::bbb::ccc for reducing the amount of typing (it may also improve readability in some cases).

I am not sure, however, what is the best way to achieve this renaming across all the files in a project. The straightforward approach (i.e., to rename long namespaces in a per-use basis) might lead to end up using different short names for the same fully qualified name in different files. So, I was thinking to come up with a more consistent way to do this.

For instance, let's assume something like:

project
  |- client
  |   |- core
  |   |- plugin
  |   |- util
  |- server
      ...

I was thinking to create one header per directory including the reduced names. For instance, project/client/core/core.h would contain namespace pr_cl_core = project::client::core (I know the example for this short name is rather poor, but in real projects they make more sense). Then, I would include core.h into all the header files in project/client/core so that when a header from that directory is included in, let's say, project/client/plugin/plugin_foo.h, the short namespace versions are readily available.

Is this a good approach to do so? Is there any other better way?

I have found several questions on C++ namespaces on SO (for instance, 1 and 2), but none of them relates to how to solve namespace renaming in a project-wide manner.

EDIT: Additionally, such a mechanism could be used to systematically rename long namespaces (such as Boost's ones) for a whole project. For instance, I typically rename some namespaces like:

namespace ip = boost::asio::ip;
namespace ptime = boost::posix_time;

Currently I do this on a per translation-unit basis, but I would like to do it using a global approach for the whole project.

Answer 1

I would argue that if you repeatedly have to type long namespace names, then something is wrong in your namespace hierarchy.

Suppose you would have the same with classes, repeatedly finding yourself typing obj->sub()->subsub()->some_method(). This would be a violation of the Law of Demeter. In the case of classes, you would refactor your code (by writing wrapper functions) so that classes down in the hierarchy only have to access methods one level up.

The same should be done with namespaces: if you have to call project::client::core then you should write wrapper functions/classes in client to expose the necessary interfaces to project. If you need to do this all over the place, why not flatten your namespace structure so that client and core are at the same level?

The fact that Boost uses nested namespace is only partly true, because most of the nested namespaces like aux and detail are not supposed to be called by clients. E.g. Boost.MPL is a really good example of a library that is careful not to gratuitously expose nested namespaces.