Should class names reflect namespace name?

Question

Is it generally considered good practise for a class name to reflect the namespace name it exists under, or should the namespace name implicitly be considered part of the class name?

For example, suppose I have a collection of classes which all act to filter a class Foo:

class FooFilter
{
 public virtual bool operator()(const Foo& obj) const = 0;
};

Subtypes could be called HappyFooFilter, SadFooFilter, ... etc.

Now if we wrap these into a namespace, we have something like:

namespace fooFilter
{
 class FooFilter ...
 class HappyFooFilter ....
 class SadFooFilter ...
 etc ....
}

But this contains a redundancy in the class names (e.g. fooFilter::HappFooFilter). So with the introduction of the namespace fooFilter, should the class names change to reflect this new structure?

namespace fooFilter
{
 class Base ...
 class Happy ....
 class Sad ...
 etc ....
}

• MJumper: Are you refering to c++ since this is your prefered language? Or are there specific standards in c++ meaning the anwser could be different than for other languages?
• Daniel: @MJumper The former, but c++ does have unusual namespace rules that may affect answers.
• MJumper: Is there a specific rule which you would consider unusual that could lead to a different answer?
• Daniel: @MJumper I'm not an expert here as I haven't used namespaces much, but my understanding is Koeing lookup does change the way 'interfaces' are viewed in c++ compared to other languages (e.g. free functions are considered part of a classes interface). But I'm not sure how this might affect answers to this question directly.
• Matthew: I think it generally considered bad form to append the namespace to each class name. So much so that it has a pejorative term called "smurf naming".

Answer 1

The problem is that your example is vague and your names are anemic. If we make them good robust names doesn't the choice become obvious?

namespace ImageFilter
{
 class BasicFace ...
 class HappyFace ...
 class SadFace ...
}

verses

namespace ImageFilter
{
 class BasicFaceImageFilter ...
 class HappyFaceImageFilter ...
 class SadFaceImageFilter ...
}

This smurf naming anti pattern has tempted me in the past as well. I've come to feel it's the result of trying to keep anemic names on life support. Rethink all the names and try again. It's a pain to do but it makes for better code.

Answer 2

Naming things is hard, and part of making the right decision is to understand what specifically the repeated name part expresses.

A prefix that is merely a company name is usually redundant, e.g. there is no reason to declare an ACMEString class within an ACMEUtil package.

A prefix that pervasively affects everything you do in the domain can sometimes merit repetition, e.g. if you have a parallel_search module it could make sense to have a parallel_index routine in it to distinguish it from the normal indexing that the project also contains.

But Foo is simply a generic placeholder, so it's hard to judge which situation holds. I'm afraid we need more details about your specific case to give a recommendation.

Answer 3

Since i'm not familiar with c++ i'm answering in a more design-specific way.

The name of class describes it's functionality, while a namespace includes a wider spectrum of classes sharing one type of function or use case.

So at first it looks like you could refactor your *Filter-classes and all of your classes work just fine. Now you're implementing another class named Happy contained in a namespace called moods.

namespace moods
{
 class Happy...
}

If another class Bar uses both of your classes which of your Happy classes will be used? How do you know which of your classes you're currently using?

So since your former classnames are describing the function of your classes to you which for example Happy does not i would stay with your current naming. Even if it seems redundant in your current state you never know what happens next.