Question

I find myself often with a situation where I need to perform an operation on a set of properties. The operation can be anything from checking if a particular property matches anything in the set to a single iteration of actions. Sometimes the set is dynamically generated when the function is called, some built with a simple LINQ statement, other times it is a hard-coded set that will always remain the same. But one constant always exists: the set only exists for one single operation and has no use before or after it.

My problem is, I have so many points in my application where this is necessary, but I appear to be very, very inconsistent in how I store these sets. Some of them are arrays, some are lists, and just now I’ve found a couple linked lists. Now, none of the operations I’m specifically concerned about have to care about indices, container size, order, or any other functionality that is bestowed by any of the individual container types. I picked resource efficiency because it’s a better idea than flipping coins. I figured, since array size is configured and it’s a very elementary container, that might be my best choice, but I figure it is a better idea to ask around. Alternatively, if there’s a better choice not out of resource-efficiency but strictly as being a better choice for this kind of situation, that would be nice as well.

Answer 1

With your acknowledgement that this is more about coding consistency rather than performance or efficiency, I think the general practice is to use a List<T>. Its actual backing store is an array, so you aren’t really losing much (if anything noticable) to container overhead. Without more qualifications, I’m not sure that I can offer anything more than that.

Of course, if you truly don’t care about the things that you list in your question, just type your variables as IEnumerable<T> and you’re only dealing with the actual container when you’re populating it; where you consume it will be entirely consistent.