Coding Standards – Problems with Avoiding Smurf Naming Classes with Namespaces

coding-standardsnaming

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?

Best Answer

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.

Related Topic