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
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
Configurationclass. It could have been called
WartmongerConfigurationbut it's in the Wartmonger namespace, so it's just called
Configuration. I likewise have a
Configurationclass which could be called
SmurfConfiguration, but it is in the Smurf namespace so that would be redundant. There are places in my code where
Wartmonger.Configurationand typing out fully qualified names is clunky and makes the code less readable. It would be nicer to deal with a
SmurfConfigurationand (if it was my code and not a library)
I have a class called
Servicein my Smurf namespace which could have been called
Serviceis a facade on top of a complex Smurf library which runs Smurf jobs.
SmurfServiceseems like a better name because
Servicewithout the Smurf prefix is so incredibly generic. I can accept that
SmurfServicewas already a generic, useless name and taking away smurf merely made this more apparent. But it could have been named
Launcher, etc and it would still "feel better" to me as
SmurfLauncherbecause I don't know what a
Launcherdoes, but I know what a
SmurfLauncherdoes. You could argue that what a
Smurf.Launcherdoes 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?