48

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.

Sarah Vessels
  • 30,930
  • 33
  • 155
  • 222
  • Should be migrated to [Programmers](http://programmers.stackexchange.com), because it doesn't deal with a coding problem, but rather pertains to development practice (how to name extension methods). –  Jul 17 '13 at 17:00
  • Came here looking for a clear winning answer and was actually not surprised not to find one... I was forced to upvote both your question and **both** Reed's and Jared's answers! – Andras Zoltan Jul 01 '15 at 09:38

6 Answers6

46

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.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • 3
    I'm imagining that there's a class called `Thing` that implements `IThing`, therefore it would be confusing if it was called `ThingExtensions` but worked on `IThing`'s. But, @Sarah Vessels does not specify this... – Klaus Byskov Pedersen Apr 23 '10 at 17:45
  • @klausbyskov: there actually isn't a `Thing` class that implements `IThing`. I'll update my question. – Sarah Vessels Apr 23 '10 at 19:10
  • 1
    I would think the "Extensions" suffix kind of removes this ambiguity? – Zar Shardan Jul 24 '19 at 10:35
  • We can't "reserve" objects that begin with "I" strictly for interfaces. Example: class Integrations, class Interrupts, class InsufficientMemoryException ... – Micah Epps Jun 27 '22 at 17:59
24

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.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • 1
    I follow the framework's approach in my projects. Hasn't lead to any nasty side-effects yet. – Paul Turner Apr 23 '10 at 17:45
  • @Programming: It works great, provided you don't have a default implementation for `IThing` that's named `Thing`... – Reed Copsey Apr 23 '10 at 17:46
  • 3
    I still don't like this approach because it violates the design guidelines for type naming. In particular only prefix type names with an I if it's actually an interface. http://msdn.microsoft.com/en-us/library/ms229040.aspx – JaredPar Apr 23 '10 at 17:53
  • 2
    @JaredPar: Yes, but unfortunately, the design guidelines don't really have any guidance for naming Extension method classes - they really just talk about when to use them (ie: http://blogs.msdn.com/brada/archive/2009/01/12/framework-design-guidelines-extension-methods.aspx) Using Thing is my preference unless you're making a Thing class - in which case, ThingExtensions becomes confusing... Hopefully, there will be official guidance on this at some point. – Reed Copsey Apr 23 '10 at 18:02
  • Luckily, however, the user never uses the class name, so the extension method class name is (effectively) an implementation detail, and not part of the API. The user only "uses" and "knows" the namespace name directly. – Reed Copsey Apr 23 '10 at 18:02
  • @Reed agreed they are a bit silent on the naming convention. But in the absence of one I usually fall back to precedence and for the BCL and most of VS APIs the precedence is `ThingExtensions`. Additionally it seems unlikely the design guidelines would come out in favor of `IThingExtensions` because it would mean too much existing code was no longer up to par. My guess is they will continue to remain silent on the subject – JaredPar Apr 23 '10 at 18:10
  • @JaredPar: Does the BCL use "ThingExtensions" anywhere? Every BCL class seems to use "Thing"... This is my preference (and what I typically do) unless there is a "Thing" class, in which case it gets confusing :( – Reed Copsey Apr 23 '10 at 18:12
  • @Reed, Not that I know of. The new Visual Studio APIs have the `ThingExtensions` pattern in several places. – JaredPar Apr 23 '10 at 18:29
  • @JaredPar `System.Web.Mvc.Html` has plenty, but the name doesn't imply the extended class. Rather, it groups the extension methods by subject, such as `FormExtensions` or `ChildActionExtensions`. There is also `AjaxRequestExtensions` at `System.Web.Mvc`, which extends `HttpRequestBase`. All of theses didn't exist at the time the above comments were added, though. – Tsahi Asher Dec 24 '15 at 07:24
  • Roslyn has class ISymbolExtensions: https://learn.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.isymbolextensions?view=roslyn-dotnet – Denis535 Dec 24 '20 at 00:33
3

I would prefer putting it in a folder (and namespace) called Extensions and naming it IThingExtensions.

Klaus Byskov Pedersen
  • 117,245
  • 29
  • 183
  • 222
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?

Community
  • 1
  • 1
Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
3

I've taken a slightly different approach, and rather than suffix with Extension reversed the naming strategy to prefix the class containing the extension methods with Extend; my rationale is as follows:

  • As pointed out in Reed Copsey's answer, very (very) seldom will client code reference the containing class directly as the very point of extension methods is to emulate reference methods. They won't see the classes, so your class naming convention choice should have insignificant impact.
  • The classes must be static, and thus you'll never instantiate them. Therefore you never end up with the semantic oddity of new ExtendThing() as far as naming is concerned.
  • All of your Extend* classes are visually grouped with alpha file sorting.
  • And with respect to your question specifically, there isn't any interface naming prefix confusion; you can have ExtendThing and ExtendIThing and (IMO) their intent and target is clear.
namespace MyCompany.Extensions
{
    public static class ExtendObject { }

    public static class ExtendDateTime { }

    public static class ExtendIEnumerable { }
}
Dan Lugg
  • 20,192
  • 19
  • 110
  • 174
2

I am not aware of any standard convention for this. I would use either ThingExtensions or ThingInterfaceExtensions. I would stay away from IThingExtensions as you also suggested.

Tom Cabanski
  • 7,828
  • 2
  • 22
  • 25