When to choose IEnumerable

When a method returns a collection it’s very common that the return type would be IEnumerable, in fact most people don’t even know why they are returning IEnumerable; they simply choose that as the most generic representation of a collection.

In order to explain why and when you should use IEnumerable I’ll step back for a moment and look at a simple method. We usually take parameters in and return a class (or void). When I look at a method I generally make assumptions on how does that code works based on its name, parameters and return type. Let’s look at the following code as a case study.

Case A
public int Multiply(int a, int b)

Case B
public void Multiply(int a, int b)

On case A we assume that providing a and b the method will return to me the result of the multiplication of a and b.

On case B though I assume that the multiplication of a and b will somehow impact the behaviour of the system, for example if this method is inside a Tax class and a represents principal and b represents tax percentage the code might change a property in the class called Total.

We can now clearly understand how choosing the parameters your method takes and the return type has a direct impact on how people use and understand your code.

Now lets get serious and talk about a big misunderstood interface and how many developers choose that interface as a return of their method without a good reason and what are the impacts of that.

IEnumerable<T>

I’m a very self-critical person and every time I choose a return type I ask myself “why am I returning this class, what is the message I’m trying to convey returning this class?” and when it comes to IEnumerable I just didn’t have an answer, it’s everywhere it’s almost like a silver bullet with the following condition:

If the class returns a collection then you should return IEnumerable.

I tend not to like that answer because it doesn’t tell you the real reason why is that, who said that if you return a collection you should return IEnumerable? so I went into the rabbit whole.

First things first, what does the interface IEnumerable represents?

From MSDN: Collections that implement IEnumerable<T> can be enumerated by using the foreach statement.

The key information here is “can be enumerated” which means not necessarily enumerated but it might be, that gives you the power of building Expression trees before enumerate the final expression.

That is the reason why when you are adding .Where(…).OrderBy(…) you are not actually getting the results you are just building the expression tree because the type that those methods return are not yet enumerated, at the moment you call .ToList() or engage into a foreach or basically when you decide to enumerate that expression then you either go to database or materialize that collection.

I’m writing all this to tell you to think twice when you are returning a IEnumerable because you might be sending an incorrect message for the person that is reading your method, you are telling them that the object you are giving them can be enumerated but not necessarily enumerated, in other words telling them that they can participate on the construction of a expression tree before materialize the results.

Needless to say 90% of the times I saw a method returning IEnumerable this is the last line of code.

return someObject.ToList()

That means the collection is already materialized, the most appropriate type to return is ICollection onwards (meaning also IList, etc…). To be honest I would return a List not its intenterface but that is a topic to talk on another time.

I hope you have enjoyed the reading and in the future ask yourself those two questions “why am I returning this class, what is the message I’m trying to convey returning this class?”