[b0zhidar]

What are advantages/disadvantages of using both?
I am really looking forward to hear some awesome answers and learn something new.

[Skydiver]

List<T> actually just uses an array internally if you look at the implementation.

[andrewsw]

Quote

It is rare, in reality, that you would want to use an array. Definitely use a List<T> any time you want to add/remove data, since resizing arrays is expensive. If you know the data is fixed length, and you want to micro-optimise for some very specific reason (after benchmarking), then an array may be useful.

From SO.. and Google

Use a list for a shopping list (unordered, can add or remove items) and an array for a top-ten, where order is significant, and it is of fixed dimensions

This post has been edited by andrewsw: 10 February 2013 - 05:34 PM

[b0zhidar]

So I should use arrays for fixed small length, and List<T> for more dynamic programs ?

[Momerath]

Size of the array has nothing to do with it. An Array has less overhead than a List<T> and is generally used when you have a fixed size of items and the size isn't going to change (though it can). List<T> is used for a more dynamic 'array', in which the size is more variable and you'll be adding and/or subtracting items.

A lot of times it will be a judgement call. If I'm searching a file for the word 'cat' and want all the lines that contain 'cat', do I return an String array or a List<String>? It's easier internally to the method to use a List<String> as we'll be adding to it as we find lines, but once you are done, it's a fixed size so do we return an String[]? Sometimes this type of thing will be determined by the coding standards of your organization.

The best advice I can give is be consistent. It will make others (and yourself) have an easier time when they look at your code 2-3 years down the line.

[Curtis Rutland]

Quote

Definitely use a List<T> any time you want to add/remove data, since resizing arrays is expensive

I'm not sure that makes sense, considering that List<T> uses an array for its internal implementation, so the operation would be just as expensive. The difference is that they have already implemented it in a fairly optimal way (growing the array efficiently instead of just by 1) and they've already written it so that you don't have to.

IMO, Lists or other data structures are going to be what you want to use 90% of the time. In fact, in many cases you can abstract that even further. If you're writing a method that takes a List<T>, but you aren't going to use any list-specific methods, you can usually abstract that to IEnumerable<T>. Then the method could take an array, a list, or any other IEnumerable<T> that you might use later, like the result of a LINQ query.

But generally, your use will be determined by your circumstance. If you will not need to modify the collection itself after you create/fill it, an array is probably best. For instance:

public static readonly string[] AcceptableNames = new [] { "Tom", "Dick", "Harry" };

You will never add to/remove from that collection at runtime, nor do you even want to be able to. It doesn't make sense to add the overhead of a List when you don't want to be able to take advantage of it's features.

In almost every other case, a List (or more appropriate data structure) would be preferable. Be aware that other data structures exist that may be more appropriate for your situation. I give an introduction to some of them here:

http://www.dreaminco...ic-collections/

Another that I did not cover that you should be aware of is Dictionary<TKey, TValue>. That one is exceedingly useful and also very efficient when used correctly. Check it out.

[AdamSpeight2008]

I'd say in most cases you want a read-only view of the list<T> not a reference to it.
So either return on new instance of a list<T> or return and IEnumerable<T>