Naming types in a namespace by the .NET Framework Design Guidelines

Question

I'm having some problems to come up with a sane type naming scheme for our new line of applications. I want to follow the .NET Framework Developer's Guide - Design Guidelines for Developing Class Libraries, but I'm starting to wonder if that's such a good idea.

I'd like to use the Company.Product.Feature namespace scheme as a basis.

Problem 1: We have our own control and form base classes, and I want these to go into the Company.Product.Forms namespace. However, according to the guidelines, we shouldn't let our type names be Control or Form, even if they are in our own Company.Product.Forms namespace, since they will clash with system types.

Problem 2: We have some distinct feature areas in the application and I want these to go into their own Company.Product.Feature namespace. Lots of these features have similar design, with a controller and some views, so under each Company.Product.Feature namespace I'd like to have types named Controller, SomeView, AnotherView, etc. However, according to the guidelines, we shouldn't have the same type names in different namespaces.

The only solution I see to overcome these problems is to prefix the types with something that in some way makes the namespaces redundant. Or not?

Answer 1

If it makes logical sense, then do it. They are just guidelines, not the LAW. (not that you cant break that too.)

Answer 2

Having classes in the with the same name in different namespaces is just is against the guidelines for a reason, it makes reading the code just a little bit harder because when you see "Controller" you have to mentally map it to "Feature1.Controller" or "Feature2.Controller".

I would prefer to use Company.Product.Features.Feature1.Feature1Conroller with the redundant information or maybe Company.Product.Features.Feature1Controller if it bothers you (and I personally don't like having too many namespaces).

But feel free to break the guidelines, rules are there to make you think before you break them :-)

Answer 3

I'd prefer Company.Product.UI, for some reason. I would use that naming for the web, too.

Regarding problem 1, if these are base types, you might include Base in the class name. Then, you typically have a set of domain specific controls, which won't clash with built-in types. If you also keep wrappers for common UI controls(TextBox, DropDownList etc), then i would actually recommend use a prefix for them, maybe this prefix is an abbreviated name of the product. And then, if you do that, then you might want to be consistent, and do it for all types, regardless of whether they are ambigious names or not.

I tell you from my own experience. You'll end up constantly hovering over variables to see their full type names, etc, you will use aliasing etc.. The code will be harder to read.

Problem 2: While at GUI layer, i tend to break these rules, because you will want naming consistency(common verbs; Show,Edit,List). If the guideline tells you otherwise, i would believe it is because it is simply not specific enough.

Answer 4

Microsoft clearly favors some redundancy. A common example is:

System.Xml.XmlDocument

General class names, even bound within a proper named namespace can cause headaches for the many programmers who like to avoid fully qualifying their class instantiations. "Document" could be an Xml, Html or word document. This ambiguity will cause endless confusion if you happen to import more than one namespace with a "Document" class.