Am I using namespaces wrong?

Question

I'm obsessed with organization - it's probably the real reason why I enjoy coding. So I namespace everything. But I'm just curious if I'm doing it wrong by being redundant.

Consider this, which I think is correct

namespace System {
   class File {};
   class Monitor {};
   class Logger {};
}

Now consider this, which is what I seem to be doing

namespace System {
   class SystemFile {};
   class SystemMonitor {};
   class SystemLogger {};
}

Am I being redundant? It's just that, SystemFile is a file in the system. SystemMonitor monitors the system.

In use cases, which would you prefer?

class Application {
   public:
      System::Monitor monitor;
      // or
      System::SystemMonitor monitor;
};

Answer 1

Am I using namespaces wrong?

Wrongly. It's an adverb.

And the answer is probably.

In use cases, which would you prefer?

There are several reasonable tests. Is one easier to read, easier to say, easier to type, easier to fit in a readable expression or otherwise easier to use?

Can you take something out without impairing clarity, legibility, usability or correctness?

System::SystemMonitor monitor;

So, in my head this sounds like "system system monitor monitor".

Why not System::SystemMonitor systemMonitor? Or System::SystemMonitor::Monitor systemMonitor? Because they add more typing with no extra information and no benefit.

Conversely, if we start from System::SystemMonitor and simplify to get System::Monitor - can you see any downside? I can't, and if you can simplify something while keeping it clear and correct, you should generally do it IMO.

---

There are a couple of valid reasons to prefix types with the module name. One is that you're writing C, and the other is that you expect people to inject the whole namespace with using. You already ruled both of those out, so you have no excuses left for making your type names worse.

Answer 2

It depends of course of your intent.

If you intend to avoid naming conflicts and use primarily qualified names, the lean approach would be less redundant and easier to read: System::File is more convenient than System::SystemFile

If on the other side you prefer to inject full namespaces with using, then of course SystemFile would be less ambiguous. But what sense does it makes to create very specific namespaces in the first place, if it is for dissolving them in some kind of global magma afterwards.

Then, comes the question of consistency. Suppose that after a while, you decide to nest your System in a Platform namespace. With the lean approach you need not no worry: it’ll be Platform::System::File. With the redundant approach, you’ll need to decide if tou keep SystemFile, or if you go for Platform::System::PlatformSystemFile. So your names start to be coupled to the namespace organisation. This goes against the principle of separation of concerns.

Then come more advanced namespace strategies. Suppose that in reality you have a MacOS namespace and a a WindowsOS namespace, each implementing a slightly different File. At compile time you do some configuration, using namespace alias. For example:

 namespace System = Platform::MacOs;
 ....
 void doSomething() {
      using System::File;    // works regardless of alias choice
       File xxx; 
        ...
  }

So, separation of concerns, i.e. keeping “item” names independent of the enclosing namespace offers you much more flexibility.