C# naming convention for extension methods for interface

Question

I typically name my C# interfaces as IThing. I'm creating an extension method class for IThing, but I don't know what to name it. On one hand, calling it ThingExtensions seems to imply it is an extension class to some Thing class instead of to the IThing interface. It also makes the extension class be sorted away from the interface it extends, when viewing files alphabetically. On the other hand, naming it IThingExtensions makes it look like it is an interface itself, instead of an extension class for an interface. What would you suggest?

Edit: there is not a Thing class that implements IThing, in response to some of the comments.

Answer 1

I definitely prefer the name ThingExtensions over IThingExtensions. The reason being that to most programmers an I prefix on a type implies that it is an interface. This is both a very common pattern and part of the .Net Design Guidelines.

Adding an I prefix for the extension method case breaks both assumptions and established guidelines.

There is also precedence for this in the Base Class Library. The majority of the extension methods available for IEnumerable are contained in the type Enumerable.

Answer 2

I, personally, would use IThingExtensions.

From a usability standpoint, the end user never sees this class - they only include it's namespace. If the namespace is the same as IThing, then it doesn't matter - they'll already have it.

That being said, I think that the fact these are extensions for any IThing makes IThingExtensions the most clear. If you have a Thing class, calling this ThingExtensions may seem ambiguous (are you extending the interface or the implementation itself?).

That being said, the framework uses a very different approach. The framework's approach is to use a class named Thing to extend IThing. For examples, see Enumerable (extending IEnumerable) and Queryable (extending IQueryable). This would also be a very good option.

Answer 3

Most programmers I know put all of their extension methods for an application in a static class called ExtensionMethods (or something like that), regardless of the class the extensions modify, and then they put this class into their main program namespace.

Their rationale is that, if you put the extension method in the same namespace as the class it modifies, you can confuse the method with the methods that are part of the actual class, which suggests that the extension method is part of the original functionality when it isn't.

Their isn't universal agreement on this, of course. See here: How do you manage the namespaces of your extension methods?