Is it good practice to add new classes to framework namespaces?

Question

A long time ago, I remember reading a quite strong recommendation from Microsoft against adding your own classes to framework namespaces. I've been unsuccessfully searching for it.

The main reason I remember is that a subsequent version of the framework might ship with a class name collision.

Are there any other reasons? Would you ever recommend adding your own classes to a framework namespace? Is there any extant official guidance on the matter?

Is common sense not good enough for you? The names are a pretty good indicator: `System` and `Microsoft` obviously do not belong to you or your company. Are you in just search of something official to convince a colleague? — Cody Gray - on strike, May 19 '11 at 07:37
The latter. There's tons of example code around throwing things into System.Collections.Generic, or System.Linq (presumably so the lazy consumer doesn't have to add additional "usings"). I'm trying to break the cargo-cult. — Iain Galloway, May 19 '11 at 07:43
I must admit, I've *never* seen example code throwing things into `System.Collections.Generic`. Maybe it happens with LINQ; I'm still kind of avoiding that whole arena. I had no idea this was a cargo-cult. — Cody Gray - on strike, May 19 '11 at 07:45
The first example of it I saw was PagedList: http://blog.wekeroad.com/2007/12/10/aspnet-mvc-pagedlistt/ (strangely, the author here has it in System.Web.Mvc, which is surely the wrong place for any number of reasons!), or yeah especially System.Linq: http://www.coderenaissance.com/2011/02/extending-linq-to-objects.html, http://blog.robvolk.com/2009/05/linq-select-object-but-change-some.html, http://brandonatkinson.blogspot.com/, http://geekswithblogs.net/bdiaz/Default.aspx - I think it's common enough to warrant discussion. — Iain Galloway, May 19 '11 at 08:00

score 4 · Accepted Answer · answered May 19 '11 at 07:49

The only case where you want to have a class in a namespace that does not belong to you when you are trying to stub something that no longer/yet exists however is used in a code-base you don't want to change.

For example I have written a HashSet implementation and placed in the System.Collections.Generic namespace for an application that was being targeted to .NET 2.0 when .NET 3.5 was in beta. I knew that we will upgrade to .NET 3.5 and removed this class when the time come.

score 3 · Answer 2 · edited Jun 20 '20 at 09:12

It seems pretty clearly stated here:

Naming Conventions

.NET Framework types use a dot syntax naming scheme that connotes a hierarchy. This technique groups related types into namespaces so they can be searched and referenced more easily. The first part of the full name — up to the rightmost dot — is the namespace name. The last part of the name is the type name. For example, System.Collections.ArrayList represents the ArrayList type, which belongs to the System.Collections namespace. The types in System.Collections can be used to manipulate collections of objects.

This naming scheme makes it easy for library developers extending the .NET Framework to create hierarchical groups of types and name them in a consistent, informative manner. It also allows types to be unambiguously identified by their full name (that is, by their namespace and type name), which prevents type name collisions. It is expected that library developers will use the following guideline when creating names for their namespaces:
CompanyName.TechnologyName
For example, the namespace Microsoft.Word conforms to this guideline.

And the "Design Guidelines for Developing Class Libraries" carry a similar rule:

The general format for a namespace name is as follows:
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
For example, Microsoft.WindowsMobile.DirectX.

Do prefix namespace names with a company name to prevent namespaces from different companies from having the same name and prefix.

Do use a stable, version-independent product name at the second level of a namespace name.

Do not use organizational hierarchies as the basis for names in namespace hierarchies, because group names within corporations tend to be short-lived.

The namespace name is a long-lived and unchanging identifier. As organizations evolve, changes should not make the namespace name obsolete.

Do use Pascal casing, and separate namespace components with periods (for example, Microsoft.Office.PowerPoint). If your brand employs nontraditional casing, you should follow the casing defined by your brand, even if it deviates from normal namespace casing.

Consider using plural namespace names where appropriate. For example, use System.Collections instead of System.Collection. Brand names and acronyms are exceptions to this rule, however. For example, use System.IO instead of System.IOs.

Do not use the same name for a namespace and a type in that namespace. For example, do not use Debug for a namespace name and also provide a class named Debug in the same namespace. Several compilers require such types to be fully qualified.

And:

The core namespaces are the System.* namespaces (excluding the application and infrastructure namespaces). System and System.Text are examples of core namespaces. You should make every effort to avoid name collisions with types in the core namespaces.

Do not give types names that would conflict with any type in the core namespaces.

For example, do not use Directory as a type name because this would conflict with the Directory type.

But, of course, you can do it if you really want to.

score 2 · Answer 3 · answered May 19 '11 at 07:33

There is a recommendation to use Company.Product.Component as namespaces. This may include not using Framework namespaces in your own product I think. See MSDN: Names of Namespaces (Design Guidelines for Developing Class Libraries ).

Personally I'd never use System namespace for my own classes, just as they don't belong to the .NET framework. Neither I'd use java.lang in Java. However, this is just my personal opinion.

Hope that helps.

Cheers, Matthias

Is it good practice to add new classes to framework namespaces?

3 Answers3

Naming Conventions