> As a regular code reviewer, I’ve grown to dislike extension methods quite a bit as it violates the principle of least surprise.
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.
Yes this is a use case but I would hardly call it the common one. I agree with GP, it really makes things harder to read not knowing if it's an actual method on a class or just a static helper function with syntactic sugar on top.
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.
Yes, done well it adds that benefit and if the extension method is universal to the type then proceed ahead with some caution. LINQ is a great example of this.
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.
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.