Recommended way to prevent naming pollution by helper classes in C#?

Question

I often come across the pattern that I have a main class and several smaller helper classes or structs.

I'd like to keep the names of thoses structs as clean as possible. So when I have a class that's called CarFinder that heavily makes use of some special Key object that is only (or mainly) used internally, I'd like to call that object Key instead of CarFinderKey.

Everything to remove all the extra fuzz that distracts me from when I try to understand the class while reading it.

Of course I don't want to pollute the rest of the code with a small helper class that is called Key - it most likely will clash and confuse.

In a perfect world I would have liked to have a keyword like internal to this namespace, but as that does not exist that leaves me the following options that I can think of:

---

1. Use internal and put the class in a different project.

Advantage: Perfect encapsulation.

Disadvantage: A lot of organisational overhead and unnecessary complicated dependencies.

Note: I'm not talking about really large self contained systems that undoubtedly deserve their own assembly.

---

2. Put it in a different child namespace, like CarFinding.Internal

Advantage: Easy to implement.

Disadvantage: Still can pollute when the namespace is accidently imported.

---

3. Put the helper class as a child class within CarFinder.

Advantage Doesn't pollute internally and can even be promoted as a public helper struct that is exposed to the outer world with CarFinder.Key

Disadvantage Have to put the helper class within the same file, or encapsulate it in an external file with public partial class around it. The first one makes a file unneccesary long, the second just feels really ugly.

---

4. Anyway call it CarFinderKey

Advantage Easy to implement.

Disadvantage Adds in my opinion too much fuzz to CarFinder. Still unncessary pollutes the naming, just with a name that is not likely to clash.

---

What is the recommended guideline?

Answer 1

Personally, I don't mind the extra "fuzz" caused by CarFinderKey, and here is why: Once worked on a very large project where we tried to use namespaces to disambiguate names.

So as you expand your system, you can very easily end up with 10 tabs open in your code editor, all named "Key.cs". That was seriously not fun.

Answer 2

It's opinion based. Anyway, I would:

1. try to make it a private nested class of CarFinder, which usually fails because the Key needs to be passed over to CarManager, you know what I mean. Public nested classes are discouraged.

2. I would put it into a sub-namespace called Core, a common name for internal stuff. For me, Core is "namespace internal" by naming convention.

3. The larger the project, the longer names you need. CarFinderKey is still a valid option.

I would never create additional assemblies just for this. It just doesn't feel right.