As a regular code reviewer, I’ve grown to dislike extension methods quite a bit as it violates the principle of least surprise.
For some reason and unfortunately, the ASP.NET Core team seems to promote this feature quite a bit.
As a regular code reviewer, I’ve grown to dislike extension methods quite a bit as it violates the principle of least surprise.
For some reason and unfortunately, the ASP.NET Core team seems to promote this feature quite a bit.
I disagree. The common use case for extension methods in ASP.Net Core apps is to extend the builder to apply configurations like all other projects. This pattern is so pervasive that the surprising outcome would be if a member function was not an extension method.
I have begun writing all static method calls as static method calls even when they are defined as extension methods. It's a little less terse but that's worth the decreased surprise. You can do this with the ASP.net configuration calls as well.
Where it falls apart is when it turns out that slightly different behavior is needed based on sub-type.
The right thing is to then move past the extension method, but it's more compelling to take the short-term gains of bolting-on more logic into the extension method.