Naming an Extension Method Class

Question

I'm just posting this for pure curiousity on what other teams have named their classes that contain .NET 3.5 extension methods.

Extensions.cs ExtensionMethods.cs Helpers.cs

what do you name yours and why, what's the intent of the name you chose and why did you chose one vs. another to hold extension methods?

Not that it's a big deal, you might tell me "Who fing cares, just pick one a**hole" but I'm just curious...to me naming is a huge part of OOP.

Answer 1

We usually name ours after the class that they are extending, i.e. StringExtensions.cs, ListExtensions.cs etc.

Answer 2

I name my extension method file in the following format

{ClassNameBeingExtended}Extensions.cs

Answer 3

I name mine with what they extend:

StringExtensions.cs
DateTimeExtensions.cs
...

Answer 4

I tend to separate them based on subject, so I can include only what I need, so I use something like SharepointExtensionMethods.cs

Answer 5

Do what .net framework does.
Enumerable for IEnumerable, Queryable for IQueryable.

Yes, that is only for interfaces.
For classes, it makes sense to suffix the class name with Extensions (e.g. stringExtensions).

Answer 6

Create a namespace for all your extension methods. Put the extension methods in classes related to the class/type you extend. For instance: MyProject.Extensions.StringExtensions

Answer 7

We use ...

Company.Common.Extensions.<Class or Interface that is extended>Extensions

For example ...

Company.Common.Extensions.ListExtensions

in file ListExtensions.cs.

Answer 8

what do you name yours

ClassExtensions

or

InterfaceExtensions

For example, StringExtensions in StringExtensions.cs or IEnumerableExtensions in IEnumerableExtensions.cs.

They are in a namespace like OurCompany.OurAssembly.Extensions.

why

It's a consistent naming scheme so that it's easy to discover and locate extensions.

what's the intent of the name you chose

To clearly describe the purpose of the enclosed code.

why did you chose one vs. another to hold extension methods?

This naming scheme seems to be the simplest that fits the bill of being consistent, easy to discover and locate, and clearly describes the purpose of the enclosed code. If there are others that are equally simple, well, a rose by any other name is still a rose.

Answer 9

I am not a fan of doing TypeNameExtensions. It omits why you are extending the type. I understand it is uniform, and thus requires little thought, but also provides little information.

It makes one bucket for every extension to that type. If you have two features that are completely unrelated, should they be organized together just because they extend the same type? You end up with large, incohesive static classes that change with every new feature. SRP and OCP go out the window.

I like to name my extension classes after the feature they are enabling. For example, I have extension methods FormatCurrent and FormatInvariant on string which help with globalized code. They are declared on the GlobalizedFormatting static class. No matter how many other extensions are added or removed from string, this class doesn't have to be touched because it is organized by feature.

My exception is for classes which create a functional API, such as Enumerable and Queryable. Naming them after the feature's core interface seems clean.

Answer 10

I usually have a single class named Extensions with all of my (relatively few) extension methods.

I don't think it's worth splitting them by type unless you have more than 4 or 5 extension methods extending the same type.

I do not think that extension methods should be put in their own namespace; this means that you always have to include that namespace when using the extension methods, which can be annoying and can also be a roadblock for beginner developers working on the code.

Answer 11

Like others here, I also tend to do StringExtensions, IEnumerableExtensions etc... The one thing I do like to do though is to put them in the same namespace the original class your extending is in. IE:

namespace System
{
   public static class StringExtensions
   {
      public static string SomeExtension(this string s){};
   }
}

This way, just by referencing the assembly, I have access to my extension methods. Don't need to add any using statements at the top.