1. Simple or associative

2. Random access capability

3. Lookup speed

4. Random insertion speed

5. Edge insertion speed

6. Random deletion speed

7. Edge deletion speed

8. Speed to empty

9. Time to count

10. Zero-based indexing

11. Native sorting capability

12. Thread safety

13. Interoperability

14. Platform portability

15. Memory requirement

16. Construction versatility

17. Native bsearch support

18. Speed of set operations

19. Code readability

20. Least effort to migrate

1. Simple or associative:

If you want to store a few elements in a random order then you don’t need an associative collection. Simple lists are IList<T> based where as associative collections are IDictionary<TKey,TValue> based.

2. Random access capability:

If you regularly need to access elements, you would need a collection that supports this functionality to boost performance. Mostly, random access capability is offered by zero-based indexing. Containers that implement IList offer this functionality.

3. Lookup speed:

Lookup speed can be crucial in the selection of associative containers. More the speed, the better. Normally, hash-based implementations outperform tree-based or list-based implementations. Thus, accessing an element in SortedDictionary<TKey,TValue> is faster than SortedList<TKey,TValue>.

4. Random insertion speed:

If there are a lot of insertions at random locations in the collection, then you should consider how fast you can insert a few elements at arbitrary locations inside the collection. LinkedList<T> offers faster random insertion than List<T>.

5. Edge insertion speed:

If you know that there will be many insertions at the edges (start or end) of the collection, choose one that is programmed to offer a faster speed. For example, Stack<T>, Queue<T>, or LinkedList<T>. Inserting in an array-based container, such as List<T>, offers the worst performance as all the elements beyond the point of insertion have to be shifted.

6. Random deletion speed:

If there are a lot of deletions at random locations in the collection, then you should consider how fast you can delete a few elements at arbitrary locations inside the collection. LinkedList<T> offers faster random deletion than List<T>.

7. Edge deletion speed:

If deletions occur only at the extreme ends of the collection, then you should consider collections optimized for that, such as Stack<T>, Queue<T>, or LinkedList<T> over List<T>.

8. Speed to empty:

In many situations, you need to clear all the elements of the collection, perhaps inside a loop. In such situations, you should consider collections that take minimum time to clear all the elements.

9. Time to count:

It is crucial to count how many elements there are in the collection. If it takes O(n) that’s not good. In such situations, resort to collections that offer constant timecount operations. Luckily most of them do.

10. Zero-based indexing:

Zero-based indexing has become the habit of programmers of our time, thanks to C arrays and C++ vectors. If you need random access on a simple sequential collection, resort to the one that offers this, such as List<T>, rather than using the ElementAt() method.

11. Native sorting capability:

If you need to sort the collection every now and then, you can consider those that offer native sorting capabilities such as List<T> or resort to a sorted collection such as SortedSet<T>. It is better than using OrderBy() because a Lambda expression evaluation is generally slower.

12. Thread safety:

If your collection will be used in a multi-threaded environment, it is better to use new concurrent collections than a primitive locking mechanism.

13. Interoperability:

IUse collections that are more flexible, or in other words, that implement more interfaces. For example, if you need associative storage, then you can use SortedList<TKey,TValue>. However, SortedDictionary<TKey,TValue> is also good because it supports serialization. So, in future, it would be easy to serialize.

14. Platform portability:

If you are programming for a platform limited by memory, then some part of the framework will be absent. Be sure to check for the availability of the collection in the framework targeted to the hardware you are using.

15. Memory requirement:

If you are in a memory-crunched system, you should also check the storage requirement of the collection. If it takes up too much memory, you might have to resort to something else. For example, if all you need is to add elements at the end and process them from the front, a Queue<T> would do just fine and you don’t need a List<T> which is more heavyweight.

16. Construction versatility:

The easier it is to create the generic container, the better. It’s better if a collection offers more variations in constructor, because you always remain prepared for unprecedented situations. You would never know how much information you would need to create a collection.

17. Native bsearch support:

Binary search is crucial to finding an item in a long list. You can always use the BinarySearch() method of an Array class; however, if native support is available, that’s better. You would save a couple of boxing and unboxing calls.

18. Speed of set operations:

Although you can perform all set operations via LINQ, resort to one proper set implementation if you need a set.

19. Code readability:

Make sure to choose a collection that signals your intent more obviously than others, resulting in more readable code.

20. Least effort to migrate:

Remember that the element of least surprise always works. Select collections that are available conceptually in several other languages.