Why Extension Methods are NOT a Code Smell

But can they be a code smell? In most cases I would say yes, for several reasons.

This blog post proposes the idea that using Extension Methods is a Code Smell. If it is, then the argument does not justify that statement.

The author gives three reasons:
"Firstly, if it is something simple, why not just implement it in the object?"
There will always be logic that has to spread across multiple objects that can only be related by interface. Inheritance should not be used just to share logical groupings of methods. Simply put properties on an interface that expose state, and then use extension methods to implement the actions that change those pieces of state. There are many good reasons not to implement logic just on the object.

"Secondly, new developers—or even experienced ones—might be confused." Sure, this is true. All developers might be confused about new ideas and methodologies. Does it mean it is bad? Of course not.

"A third scenario where I see extension methods as problematic is in the fact that they seem to be instance-based." That is the point I think. I'm not sure what actual point the author is trying to make but I think this idea is guilty of the Slippery Slope Fallacy. He actually goes to out and out to state it.

Extension methods are great because you can push functionality around just by having a class implement an interface. This does wonders for me. Of course, you could have done this before with the same Utility methods.

Ultimately, Extension methods really change nothing except for readability. I can now read right to left. The best example is using string.IsNullOrEmpty();

I no longer have to read it as string.IsNullOrEmpty(x). I just read it as x.IsNullOrEmpty() This may seem small and petty, and it is, but I think this kind of readability does wonders for communicating code to developers.

Edit: Excuse my poor initial titling, it is early :)