Maxpm
Maxpm

Reputation: 25592

Sub-Namespaces for Organization Bad Practice?

Would it be considered bad practice to use sub-namespaces for purely organizational purposes? For example:

namespace vehicles
{
    namespace cars
    {
        // Stuff here
    }

    namespace boats
    {
        // More stuff here
    }
}

I can see how this would be a problem on large projects, because it would be inconvenient to type vehicles::cars::function a lot. What about small projects, though?

Upvotes: 5

Views: 7291

Answers (4)

Stuart Golodetz
Stuart Golodetz

Reputation: 20656

Well, for what it's worth, I tried using deeply-nested namespaces on a medium-sized project a couple of years back, and it was absolute hell -- I spent my entire time writing typedefs :) In Java, packages work quite nicely, because you can just import things at the top of each .java file and not have major problems. In C++, it's a pain in the butt, because it's bad practice to put using directives/declarations in header files -- as a result, you end up either (a) fully-qualifying everything in headers (bleurgh) or (b) using lots of typedefs (also bleurgh). Not cool -- my advice would be to avoid like the plague, unless you enjoy writing things like:

centipede::autoseg::hierarchygeneration::ragbuilders::RAGBuilder<...>

That's not a type, it's a sentence...

Upvotes: 7

Stack Overflow is garbage
Stack Overflow is garbage

Reputation: 248199

Why would it be less inconvenient to type vehicles::cars::function a lot in a small project?

Remember what purpose namespaces are supposed to serve. They are supposed to avoid name clashes, and not much else.

If you invent such a convoluted namespace structure that I'm tempted to just put a few using namespace ...'s at the top of every file, then it defeats the purpose of namespaces.

It also doesn't really tell me much I didn't know already. What are you going to put in your boats namespace that I wouldn't know from the name alone was a boat? Am I going to need the clarification that "this belongs with the boats" on anything in the namespace? Most likely not, and then there's no point in having the namespace.

In general, don't ask what problems there are with using any language feature until you've found out what the advantages are. Every feature needs to justify itself. So what problem would your proposed namespaces solve?

If it wouldn't solve a real, actual problem, then it is a bad idea, regardless of anything else.

I always think it's instructive to look at different language's standard libraries.

.NET uses deeply nested namespaces with long names. The full name for a simple dynamic array is System.Collections.Generic.List<T>.

As a result, no-one ever uses the namespace. Everyone just puts a using System.Collections.Generic at the top of every file that needs to use a List.

And because of this, you're in trouble the moment you encounter another List class. You'll want to do the same with that, and voila, you have two List classes clashing.

C++ uses a very flat namespcae structure, where namespaces also have very short names.

The equivalent class in C++ is simply std::vector. As a result, people generally type out the namespace prefix, and so, when I add another vector class to my project, *it works'. There are no name clashes, because I use the std:: prefix when I want to refer to the standard library vector.

Upvotes: 11

Mr Shoubs
Mr Shoubs

Reputation: 15419

One of the reasons for Namespaces are for organisational purposes, how finely grained you make them is up to personal preference - I keep them fairly generic personally, for example I'd have TransferObjects. Vehicles, but not go any finely grained than that. Unless you have many many types, I don't see a point in going into that much detail. But that is up to you.

If it's a small project, then should the code base be relatively small and easily navigable, thus removing the need for such an approach?

Upvotes: 2

Nim
Nim

Reputation: 33645

IMHO it's not bad practice! Also consider using aliases to get around having to type the fully qualified name every time and not injecting the whole namespace where needed...

Upvotes: 4

Related Questions