C#'s Aversion to Array

I have noticed in documentation, looking at open-source code bases, and just a general sense in the industry that C# developers largely prefer to use List or IEnumerable over simple array[] types, and I'm wondering if my preference for array type is misguided. For some background, most of the time, I'm writing back-end business software; the kind of API or service that reads data from some data source, and sends back objects of that data to the caller. Most of that time, I'm doing a query from an SQL database or similar object store where the methods of access are pretty much distinct CRUD operations. There isn't much processing or derivation of data (like map & reduce or similar) going on, kind of ever. For example, I might write a method that does "search the product index and return matching products". Or "get me customer's orders between two dates". These kinds of access patterns do not imply any sort of modification need, where middle-tier code would have any business removing or adding items to the collection of things returned, its job might be to enrich the data or convert it to another format, generally only passing it through, or maybe iterating on it for some purpose. Generally though, the size of these arrays never changes. I was always taught that when designing a software component, you want to keep its context to the minimum viable amount of information. Passing an individual value rather than a whole object to a function which only needs one value from the object for example. In the case of an API that does not imply mutability, why should I want to return a type like List that implies the list is mutable? Why then do so many developers (and API designers) seem to prefer using List in returned data sets? I understand List is implemented on top of arrays and adds some convenience, but the array notation is built-in to the language, and syntactically simpler (and arguably more universally understood with other languages). LINQ adds most of the functionality for projection, searching, sorting, etc that array does not contain by default, and is more or less interoperable with List. Is this a hold over from the .Net Framework 1.1 dark ages of ArrayList, where array has become a bad word? Is List somehow more performant than array[] despite the overhead? Is implying mutability beneficial vs just having the caller do .ToList() if they really need to edit the data?

Jun 20, 2025 - 23:30

I have noticed in documentation, looking at open-source code bases, and just a general sense in the industry that C# developers largely prefer to use List<> or IEnumerable<> over simple array[] types, and I'm wondering if my preference for array type is misguided.

For some background, most of the time, I'm writing back-end business software; the kind of API or service that reads data from some data source, and sends back objects of that data to the caller. Most of that time, I'm doing a query from an SQL database or similar object store where the methods of access are pretty much distinct CRUD operations. There isn't much processing or derivation of data (like map & reduce or similar) going on, kind of ever. For example, I might write a method that does "search the product index and return matching products". Or "get me customer's orders between two dates".

These kinds of access patterns do not imply any sort of modification need, where middle-tier code would have any business removing or adding items to the collection of things returned, its job might be to enrich the data or convert it to another format, generally only passing it through, or maybe iterating on it for some purpose. Generally though, the size of these arrays never changes.

I was always taught that when designing a software component, you want to keep its context to the minimum viable amount of information. Passing an individual value rather than a whole object to a function which only needs one value from the object for example. In the case of an API that does not imply mutability, why should I want to return a type like List that implies the list is mutable?

Why then do so many developers (and API designers) seem to prefer using List in returned data sets? I understand List is implemented on top of arrays and adds some convenience, but the array notation is built-in to the language, and syntactically simpler (and arguably more universally understood with other languages). LINQ adds most of the functionality for projection, searching, sorting, etc that array does not contain by default, and is more or less interoperable with List. Is this a hold over from the .Net Framework 1.1 dark ages of ArrayList, where array has become a bad word? Is List somehow more performant than array[] despite the overhead? Is implying mutability beneficial vs just having the caller do .ToList() if they really need to edit the data?