Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
Does Smurf.Launcher launch smurfs, or does it launch SmurfJobs? Perhaps it could be called Smurf.JobLauncher? –  Blorgbeard Mar 25 '13 at 23:06
    
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. –  tieTYT Mar 26 '13 at 1:27
    
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. –  Daniel Koverman Mar 26 '13 at 22:40
    
I'm trying to comprehend why you have a single class that cares about configuring both Wartmongers and Smurfs at all. –  Donal Fellows Mar 27 '13 at 10:43
add comment

3 Answers

up vote 5 down vote accepted

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.

share|improve this answer
2  
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 '13 at 13:27
    
.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. –  Daniel Koverman Mar 26 '13 at 22:35
add comment

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.

      Session
       ^   ^
      /     \
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.

MyCompany.HttpSession
share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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