I pulled the term smurf naming from here (number 21). To save anyone not familiar the trouble, Smurf naming is the act of prefixing a bunch of related classes, variables, etc with a common prefix so you end up with "a SmurfAccountView passes a SmurfAccountDTO to the SmurfAccountController", etc.

The solution I've generally heard to this is to make a smurf namespace and drop the smurf prefixes. This has generally served me well, but I'm running into two problems.

  1. I'm working with a library with a Configuration class. It could have been called WartmongerConfiguration but it's in the Wartmonger namespace, so it's just called Configuration. I likewise have a Configuration class which could be called SmurfConfiguration, but it is in the Smurf namespace so that would be redundant. There are places in my code where Smurf.Configuration appears alongside Wartmonger.Configuration and typing out fully qualified names is clunky and makes the code less readable. It would be nicer to deal with a SmurfConfiguration and (if it was my code and not a library) WartmongerConfiguration.

  2. I have a class called Service in my Smurf namespace which could have been called SmurfService. Service is a facade on top of a complex Smurf library which runs Smurf jobs. SmurfService seems like a better name because Service without the Smurf prefix is so incredibly generic. I can accept that SmurfService was already a generic, useless name and taking away smurf merely made this more apparent. But it could have been named Runner, Launcher, etc and it would still "feel better" to me as SmurfLauncher because I don't know what a Launcher does, but I know what a SmurfLauncher does. You could argue that what a Smurf.Launcher does should be just as apparent as a Smurf.SmurfLauncher, but I could see `Smurf.Launcher being some kind of class related to setup rather than a class that launches smurfs.

If there is an open and shut way to deal with either of these that would be great. If not, what are some common practices to mitigate their annoyance?

  • 4
    Does Smurf.Launcher launch smurfs, or does it launch SmurfJobs? Perhaps it could be called Smurf.JobLauncher?
    – Blorgbeard
    Mar 25, 2013 at 23:06
  • 3
    It's a code smell to name a class XService, XManager, etc. These don't mean anything. It's like a Util. If you're skimming the file names anything could be in there or missing from there. There's no way to know unless you look inside. I'd rename it from SmurfService to something else completely. Mar 26, 2013 at 1:27
  • 1
    It does actually launch SmurfJobs, or technically runs them to be consistent with the language of the Smurf documentation. In light of that and the other answers, I am going to rename SmurfService to SmurfJobRunner. It seems number 1 has no language agnostic best resolution as I expected. I can see instances where going with SmurfConfiguration would be the right call, but in my case I think Configuration is best even with the hassle of Wartmonger.Configuration. Mar 26, 2013 at 22:40
  • 6
    I'm trying to comprehend why you have a single class that cares about configuring both Wartmongers and Smurfs at all. Mar 27, 2013 at 10:43
  • Why do Smurf.Configuration and SmurfConfiguration feel different? Surely it's not the extra char, is it? (Shorten to Config if length is the problem.) Does Smurf.Configuration have any problems that SmurfConfiguration doesn't?
    – Pablo H
    Oct 11, 2019 at 12:58

5 Answers 5


You raise some good points.

  1. With regards to having duplicate classes, you can alias classes in C#. Use for example using ColorScheme = The.Fully.Qualified.Namespace.Outlook2007ColorScheme; See this post on StackOverflow. You've not indicated your programming language but I have inferred it from what you've written. So where you're dealing with two different projects, you can alias them as SmurfConfiguration and WartmongerConfiguration which would free ambiguity when consuming both classes.

  2. As a service is exposed to external application(s) I see no problem in branding the service with your application name, so in this case SmurfService would be valid as it would actually disambiguate groups of services in the consuming application.

I feel that namespaces should be used to avoid this style of naming. It makes it more difficult to grok the code and see at face value what a class is without reading MyCompanyMyProductMyAreaClassName. Using the aliasing technique allows you to reduce ambiguity where needed. The only time I think you should introduce complexity into your naming is, as I've pointed out in #2, when people will be consuming a service. This is where it makes perfect sense to have this style of naming because if the consumer has a variety of services it is consuming the ambiguity could be confusing.

  • 6
    aliases just muddle things up. Instead of Smurf.Service you now have SmurfService = Smurf.Service. So you might as well just have had SmurfService as the name of the thing in the first place. They have a place, but not for this particular issue. However, its probably the best answer to a problem that has no answer :)
    – gbjbaanb
    Mar 26, 2013 at 13:27
  • 1
    .The C# in me came out in my question, but I'm actually currently dealing with java and org.apache.smurfville.wartmonger.configuration. This unfortunately rules out aliases. 2 is a solid point, so I'm going to keep Smurf branding for the Service. Mar 26, 2013 at 22:35

The point of namespaces is so you can have classes of the same name from different libraries without them colliding. When you need to use the same named class from both you need to remove the ambiguity by prefixing one or both with its namespace scope.

That said, it's not really that bad to have a bunch of Smurf classes if Smurf tells you something specific about the class. The class names should be descriptive enough to give you some information about what the class does.

       ^   ^
      /     \
DBSession   HttpSession

Similarly a DBSession might take a DBRequest object which returns a DBResponse object. The HttpSession might also operate on HttpRequest and HttpResponse objects.

These are Smurf classes with a purpose.

They might live in the MyCompany namespace but MyCompanyHttpSession and MyCompanyDBSession does not give you any more information than you had before. In this case drop the Smurf and make it a namespace.


I've run up against this same point of confusion before and it's usually really a question of do we include the kind of thing it is as part of it's name.

You mention SmurfConfiguration and WartmongerConfiguration as potential kinds of configurations. You indicate that you removed the adjective (its kind) to its namespace so that what you're left with is just the vanilla Configuration. I would avoid doing that.

It's like deciding that strawberry ice cream is just ice cream in the strawberry namespace and likewise with chocolate, but what's happened is you've divorced the adjective that gives it its identity from the thing itself. It's not ice cream in the strawberry category. It's strawberry ice cream -- a kind of ice cream.

Let's imagine that in your app, you import the Strawberry.IceCream class and then start instantiating directly from IceCream.

var ic = new IceCream(); //actually I'm strawberry ice cream

This may seem well and good, up until the moment you end up importing another IceCream class. Now you're back to the original problem of having to somehow distinguish between them, which is problematic. What you wanted all along was:

var sic = new StrawberryIceCream();
var cic = new ChocolateIceCream();

Namespaces are better left to avoid potential conflicts between third parties who might incidentally represent the same concepts in their libraries. When one developer creates a library or project, however, he should name each concept uniquely and use namespaces as folders for organization only. Often the name of the folder will be found in the name of the concepts it organizes and that's okay.


It is definitely a good rule of thumb that if you've got a common prefix on a bunch of classes, then they probably deserve to go in their own namespace. To deal with the problem then, when you need to use similarly named classes from two namespaces:

1) Alias the namespaces, though I'd make it short and to the point, any natural abbreviation, maybe even just 1 letter:

using Sm = Smurf;
using W = Wartmonger;

Then always prefix wherever used and name instances appropriately:

Sm::Configuration smConf; 
W::Configuration wConf;

2) Alias the class, as suggested in other answer.

using SmConf = Smurf.Configuration;

3) Any library you have control over, consider not using the term 'Configuration'. Use thesaurus: e.g. 'Settings', 'Model', 'Parameters'. Might be more meaningful to the context anyway: E.g. if Smurf was some sort of numerical analysis module you'd written perhaps 'Parameters' would be better for its configuration. Use the particular vocabulary associated with a module's context to your advantage to come up with unique names that hold uniqueness even when mixed into other namespaces. I feel this might be kind of an answer to OP question 2.

4) Refactor code so that you don't have to mix the use of configuration from two different places. Details of that are up to you.

5) Combine the two configurations into one before you pass it into your class. Use a combined conf class to represent:

struct Conf {
    SmurfConfiguration smurf;
    WartmongerConfiguation wart;

The short member variable names are now kind of achieving the same thing as aliasing the class/namespace.

  • "Use thesaurus" -- Hard disagree on this one. Personally hate when people arbitrarily break out the thesaurus because, as a reader, name differences imply to me that the name choice was significant, and confuses the hell out of me when I cant figure it out, and drives me nuts when I'm trying to string search for related types and miss a category because of an arbitrary name choice.
    – Catskul
    Aug 30, 2023 at 15:33

Seems strange that adding one point to the name bothering you.

Wartmonger.Configuration configuration = Wartmonger.Configuration .new();

// vs

WartmongerConfiguration configuration = WartmongerConfiguration.new();

If both Smurf and Wartmonger configurations used together in one place, but separatly they are used in multiple places - then namespace is definitely good approach.

Having namespace will give possibility to use "clean" names in internal code, where with prefixes you end up using SmurfConfiguration inside SmurfService's internal code, which can become annoying everytime you will open that code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.