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.
-
I'm working with a library with a
Configuration
class. It could have been calledWartmongerConfiguration
but it's in the Wartmonger namespace, so it's just calledConfiguration
. I likewise have aConfiguration
class which could be calledSmurfConfiguration
, but it is in the Smurf namespace so that would be redundant. There are places in my code whereSmurf.Configuration
appears alongsideWartmonger.Configuration
and typing out fully qualified names is clunky and makes the code less readable. It would be nicer to deal with aSmurfConfiguration
and (if it was my code and not a library)WartmongerConfiguration
. -
I have a class called
Service
in my Smurf namespace which could have been calledSmurfService
.Service
is a facade on top of a complex Smurf library which runs Smurf jobs.SmurfService
seems like a better name becauseService
without the Smurf prefix is so incredibly generic. I can accept thatSmurfService
was already a generic, useless name and taking away smurf merely made this more apparent. But it could have been namedRunner
,Launcher
, etc and it would still "feel better" to me asSmurfLauncher
because I don't know what aLauncher
does, but I know what aSmurfLauncher
does. You could argue that what aSmurf.Launcher
does should be just as apparent as aSmurf.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.
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 asSmurfConfiguration
andWartmongerConfiguration
which would free ambiguity when consuming both classes.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.