C# extension methods have seen a rise in usage over recent years. The offical microsoft guidelines on usage state: "In general, we recommend that you implement extension methods sparingly and only when you have to" The extension method guidelines.

On the other hand Microsoft are now using them heavily in dot net core (see the microsoft extensions name space). This is particularly prevalent is asp core where the initializaion of the IServiceCollection is implemented in extension methods, for example see The service collection service extensions. Dot net core tutorials has an article listing this as a design pattern suggesting that it is best practice. Quite a few popular nuget packages also use this method to initialise services: Swagger is configured this way microsoft docs as well as mediatr their implementation

Should the guidelines be updated or should this practice be avoided? If the guidelines are to be updated what should they be?

  • 2
    think someone else asked this question a while back. Avoid was my vote
    – Ewan
    Jul 13, 2019 at 6:24
  • @Ewan I couldn't find anything quite as specific regarding the transition Microsoft are making. Avoid is also my vote
    – Adrian
    Jul 13, 2019 at 6:28
  • 1
  • 1
    I agree it is an interesting question. but you might find it gets closed as a duplicate. I mean I could simply copy paste in my answer. Which you seem to agree with and would possibly accept. What can we say other than "its logically bad practice, but MS encourage it. probably due to some guy in .net core liking the idea"
    – Ewan
    Jul 13, 2019 at 7:04
  • 4
    Could not find a duplicate, only this related question.It is surely an interesting question, however, I don't think there is a "right" or "wrong" answer to this. I would actually close this question either as "too broad" or "primarily opionated". It is something you could discuss with someone like Eric Lippert, but unfortunately, the SE sites are not for discussions. "Quora" might be a better place for this.
    – Doc Brown
    Jul 13, 2019 at 7:28

2 Answers 2


The goal of extension methods is specifically to be able to extend either classes of other assemblies or interfaces. The recommendation to use them sparingly is right, for several reasons:

  • Extension methods, when used too much, are polluting IntelliSense. This could be extremely annoying when (1) the extension methods were created in a core namespace which is using-included in nearly every file of the project, and when (2) they are extending some very general interfaces or classes, such as object.

    An example of such pollution is NSubstitute. IntelliSense becomes nearly useless in a test project which includes NSubstitute, because there are so many items which are automatically suggested for everything, that the only way to know the members of a specific class or interface would be to go see its documentation, which is a bit disappointing.

  • People who abuse extension methods could in many cases use elementary inheritance, or, in more esoteric situations, patterns such as the decorator pattern.

    A basic example I've seen recently. The code was dealing with geometrical shapes, and, among others, had to convert from meters to inches. The developer simply put two extension methods, ToInches and ToMeters for int, two other ones for double, etc. Instead, he could make an effort to make dedicated classes which encompass the value and the metric system being used, and allow conversions to other systems.

  • Extension methods make unit testing more difficult than it needs to be, as would any public static method anyway, as opposed to an instance method of an object injected at runtime, with the possibility to replace it by a mock or a stub.

  • By extending code which doesn't belong to you, you put yourself at risk of the author of the code adding the method which has the same name as your extension method, but which has a different implementation. This alone should encourage you to use extension methods sparingly, or at least limit yourself to interfaces only.

    As an example, a few years ago, a fellow developer told me a story. Their codebase had a magic method called public static string ToJson(this object x) which would, as you may imagine, return the JSON representation of an object. Nice and all, until one of the classes of a third party was updated with an addition of an instance ToJson method. It took about a week to the team to figure out why is the serialization rules suddenly changed for some of the objects, breaking the application which was consuming the service.

There are cases where extension methods are extremely valuable. LINQ is such case. But developers should be careful to limit themselves to cases similar to LINQ, instead of creating as many extension methods as they can.

  • Static methods can be injected with dependencies at runtime (including objects); that's what parameters are for. Your objection is to static state, not inversion of control. Jul 13, 2019 at 19:03
  • The last point is the biggest issue I see with extension methods. Regarding namespace pollution extension methods can be used to avoid that, by placing related functionality into a separate name rather than the core interface.
    – Adrian
    Jul 13, 2019 at 23:49
  • 1
    @Robert Harvey, what Arseni is talking about is not unit testing a static method, in which case what you’re saying makes sense. What he is referring to is unit testing a method that itself makes use of a static method from another class. The difficulty with unit testing such methods as Arseni rightfully claims, arises due to the fact that static methods cannot be mocked easily. Moq for one is certainly unable to do it. You need third party tools such as Typemock.
    – Ash
    Jul 15, 2019 at 9:34
  • @Ash: So unit test the static method separately, to prove that it works. Then there is no need to mock it. Jul 15, 2019 at 12:48
  • 1
    @Robert Harvey, I don’t think you follow. We are not interested in unit testing the static method here, there are no issues with that, as you’ve described. The issue here is unit testing methods that themselves call other static methods. Because these static methods cannot be mocked, the System Under Test is not being tested in isolation and therefore by definition, the test is not a unit test.
    – Ash
    Jul 15, 2019 at 23:18

Extension methods are just syntactic sugar for ordinary static method calls.

Extension methods make possible the ability to "spot-weld" methods onto existing types, without requiring inheritance, composition, weaving or any other language mechanisms. But they're just a proxy for an ordinary method call; they don't participate in the design of the class, nor do they add any new functionality that the class doesn't already have.

What an extension method does is turn this:


into this:


And that's all it really does.

It's arguably prettier (which is no small thing), but really, is there any other compelling reason to use extension methods?

Yes: to enable Method Chaining.

var productList = products
   .Where(prod => prod.StateOfManufacture = "CA")
   .OrderBy(prod => prod.Category)
   .ThenByDescending(prod => prod.UnitPrice)
   .Select(prod => new 
        { Name = prod.ProductName, Category = prod.Category, Price = prod.UnitPrice });

This would be very tedious without extension methods.

The advice "use extension methods sparingly, and only when you have to" is not actionable. Entire libraries and frameworks have been built using extension methods, and you never "have to."

So is it a "best practice?" My answer to that is "does it most effectively meet your specific needs?"

  • The method chaining is the primary benefit that I see them offering. In those cases it does make the code far cleaner than using the underlying static implementations.
    – Adrian
    Jul 13, 2019 at 23:43
  • @AdrianBlackburn: It can also be useful for reducing interface proliferation as, rather than creating a new interface for a single new capability, you can simply attach it using an extension method. Jul 14, 2019 at 17:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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