When it isn't right to add types to a well known namespace?

Question

For the purpose of writing a library, I found to be nice to add types to some well known namespace.

Example:

I've written a couple of extension methods for BinaryWriter and naturally put them in System.IO namespace.

Pros:

• they're readily visible and usable
• I do not end up rewriting it and shortly after discover it was already done but in an obscure namespace that had to be imported manually (though Resharper alleviates somehow this aspect)

Cons:

When there are many of them, it starts to get confusing between what are 'official' types and 'in-house' types.

Question:

Is this a good or a bad practice ?

Answer 1

Let me answer the actual question which is:

When it isn't right to add types to a well known namespace?

The question should rather be asking: when it's right to do so because usually it's never right to add anything to well know namespaces. You only do this when you want to use a very specific mechanism.

With this change in mind...

You want to do it when you want the compiler to pick your extension instead of the one provided by the framework.

Example

You might want to use (your own improved) ToList extension that has exactly the same signature as the one in System.Linq namespace. So the first thing you do is to create this:

namespace Company.Linq
{
    public static class MyCustomExtensions
    {
        public static List<TSource> ToList<TSource>(this IEnumerable<TSource> source)
        {
            ...
        }
    }
}

But it's very likely that the compiler will refuse to build your project now because it's not sure which ToList it should use.

The call is ambiguous between the following methods or properties: 'System.Linq.Enumerable.ToList(System.Collections.Generic.IEnumerable)' and 'Company.Linq.Custom.ext.ToList(System.Collections.Generic.IEnumerable)'

This means you cannot use System.Linq and Company.Linq (or any other namespace containg this extension) at the same time. This might be a huge problem in case of Linq.

You can resolve it by putting your extensions in a more specific namesapce then System.Linq, e.g System.Linq.Custom.

Now the compiler will choose your extension over the default one because your namespace is more specific.

---

When there are many of them, it starts to get confusing between what are 'official' types and 'in-house' types.

No it won't, as I've said. You won't be able to build your project if you import extensions with same signatures from two two different namespaces.

You have to decide whether your extensions should replace the original ones or you need to use a different signature. Othewirse there will be conflicts.

Answer 2

If you have enough code that you want to re-use, create a company namespace. You can organize diffrent code into different libraries as well so that you don't need to include all your company's shared code in every app.

An example of how I do it is a database class library that includes the oracle managed data access and dapper nuget packages and has a couple classes with simple interfaces to retrive data from any oracle database. This library is completely separate from our logging library which basically is just NLog all set up and wrapped for our needs. These libraries live in Company. Oracle and Company.Logger namespaces respectively.

Answer 3

I think putting the extension methods in a separate namespace is a better approach. The con you mentioned can make it difficult to determine what is custom vs coupled with the provided library. Eventually you might have conflicting signatures (method name & parameters), etc. depending on the size of your application.