3

I'm writing some tools to be used on the top a specific framework, in C#.

Most of my code should use the naming convention CompanyName.TechnologyName[.Feature][.Design], but I wonder if in some cases I should use the framework's namespace.

For example, there are some extension methods I'm implementing that make sense to be available when using a namespace of the framework. I think it's more convenient to not have to add my namespace when the framework's namespace is being used.

Besides extension methods, there are some cases of classes I wrote and inherits from the framework classes that I believe should be offered to the user of my tools along with the framework classes.

For example, if class B from the framework inherits from A also from the framework and they belong to the same namespace, why should my class C that inherits from A be in a different namespace?

Summing up, what are the dos and don'ts when writing code heavily based on someone else's namespace?

2
  • 3
    Aside from the confusion in knowing which package owns what, one big problem with adding to someone else's namespace is that it may collide with later additions to that namespace. – Chuck Adams Oct 27 '19 at 3:06
  • @ChuckAdams: Even with separate namespaces, those conflicts can still occur because you'll run into ambiguous reference errors. Any file which has both a using to my custom namespace and that of the library is prone to ambiguous references if the library namespace suddenly adds a type that already exists in my custom namespace. – Flater Oct 27 '19 at 12:26
7

Namespaces have two main functions:

  • Provide unique names for symbols;
  • Group related symbols.

For the unique names, putting your symbols in someone else's namespace is a big NO NO. As community of software developers we defacto agreed that namespace ownership is hierarchical. The framework owners and company named CompanyName decide what goes in their namespaces. If someone hijacks/squats a namespace they run the risks of name collisions. If someone else uses the squatter's software they run that risk as well.

For the function of grouping related symbols, OP does have a point for including their extension in the framework's namespace since the extensions are related to the framework. But the rule of not hijacking someone else's namespace is more important. In addition, we can argue that namespaces should follow package (assembly) structure. Missing part of the symbols because they are hidden in some package you didn't expect them to be in causes build breaks and extra work.

There are two alternatives:

  • If the framework accepts contributions, OP might offer their extensions for inclusion in the framework. Using the framework's namespace would be no problem in that case.
  • The namespace CompanyName.FrameworkExtensions clearly describes this group of symbols and is IMHO a good alternative to squatting the framework's namespace.

Namespaces perform two additional functions:

  • They indicate authorship and indicate whether the software can be trusted and what quality can be expected.
  • Specific to extension methods in C#, they allow selectively enabling sets of extension method.

For the authorship, to me there is a difference between symbols in the namespace microsoft and in acme (the fictional company where Willy E. Coyote buys his stuff which always explodes). Squatting a namespace leads people to make false assumptions about the authorship and quality of the software.

In C# extension methods are only used when they can be found via a using-declaration. Having the extensions in a different namespace allow fine grained control over when the extension methods should be used.

2
  • (1) At a very basic level, if namespaces should be bound to their assembly, why do namespaces then not automatically prepend themselves with their assembly's name? The ability to change it suggests that there are valid reasons to do so. (2) Extensions methods exist precisely to behave as if they were part of the extended type. Forcing a separate namespace effectively negates that by requiring consumers to know it's an extension method that needs to be included separately. – Flater Oct 27 '19 at 12:06
  • Re "CompanyName.FrameworkExtensions": Perl CPAN has a similar convention of appending an 'X' to package names, e.g. MooseX, MojoX, CatalystX, ... – Chuck Adams Oct 27 '19 at 16:26
1

There are some cases of classes I wrote and inherits from the framework classes that I believe should be offered to the user of my tools along with the framework classes.

I agree with Kasper here that you should stick to your own namespace in these cases. It's a matter of making clear that your class is a custom implementation.

Following your logic, we would have to put every class in the System namespace since they all derive from object. This rule just doesn't make sense, your decision to use a particular namespace is arbitrary and other people will have different opinions and interpretations.

Stick to your own namespacing, though I would agree if you decided to have part of the namespace refer to the library that's you're basing it on in cases where the underlying third party library is leaked to consumers anyway, e.g.:

namespace Roberto.MyApp.Data.EntityFramework
{
    public class RobertosContext : DbContext { /* ... */ }
}

I still expect some developers to disagree with this (as it "leaks" the dependency at least information-wise), but in the case of inheritance (as opposed to composition), a consumer using the derived class will inherently be required to know the base class as well, which means the dependency has already leaked anyway.

If you're using composition, then the above suggestion is invalid. Your composed classes act as a wrapper to ensure that your consumers don't know which library you may or may not be using, so your namespace should be library-agnostic as well.


For example, there are some extension methods I'm implementing that make sense to be available when using a namespace of the framework. I think it's more convenient to not have to add my namespace when the framework's namespace is being used.

Here I disagree with Kasper and agree with you.

Extensions methods exist precisely to behave as if they were part of the extended type. Forcing a separate namespace effectively negates that by requiring consumers to know it's an extension method that needs to be included separately.

Anyone who would be using your extended type would generally already be using that type's namespace and therefore the extension methods would be indistinguishable from the actual class methods, which is the point of extension methods.

Extension methods are just a syntactical rewrite of a static method because you don't want consumers to have to know which arbitrary static class you decided to put this method in. If you use extension methods but then require consumers to know which arbitrary namespace you've put this in, then it's just perpetuating the same issue.


if class B from the framework inherits from A also from the framework and they belong to the same namespace, why should my class C that inherits from A be in a different namespace?

Because there is no inherent grouping between two derived classes.

Take the extreme example: you and I both use Entity Framework. We both derived our context class (RobertosContext, FlatersContext) from EF's DbContext. Should we now be forced to coordinate our namespaces?

The earlier example I gave applies here too: following your logic, we would have to put every class in the System namespace since they all derive from object.

There might be cases where the derived classes belong to the same namespace, but that is not inherently the case just because they inherit from the same object.


Summing up, what are the dos and don'ts when writing code heavily based on someone else's namespace?

At a basic level, stick to your own namespace. You need clarity on which types were created by you.

Extension methods are the exception here because they specifically exist to camouflage themselves as belonging to the object they extend, and taking on the same namespace is part of that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.