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

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.

Answer 2

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.