Somebody told me this but i have not seen this anywhere and i have used it all over, i don't see why would it be bad practice.
Example of what i mean is having functions such as:
public List<SomeCustomeType> GetListOfStuff()
{
}
or
public void DoSomeStuff(List<SomeCustomeType> param)
{
}
can anyone tell me why would this be bad practice or should not be used? thanks!
No, it's not bad. It might be better to use the generic interface IList<T> than the generic class List<T>, though.
the first is better by far. it is clear that the method creates new list and return it, it is unclear who is responsible to create the second version list and what will happen if it is not empty...
Closed and Open generic types can be and are used in the framework and should be used. If you are using an incorrect type or exposing functionality you don't need, then it might be bad practice - for example, it is better to return IList<T> then List<T> as then you are not tied to the implementation and can use any type that implements IList<T>.
In a similar vein, you should only use types that expose the minumun required - better to return IEnumerable<T> than IList<T> if you only ever need to enumerate over the returned list.
In the era of LINQ and its associated extension methods, it's considered best practice to return IEnumerable<T>, even if the underlying collection implements IList<T>. The LINQ extension methods Count() and ElementAt() both have optimizations when the underlying collection is an IList<T>, so the performance impact is generally negligible.
This practice insulates the client code from the details of how you're managing the collection (maybe you'll want to use a different type of collection in the future?) The main thing to consider when following this pattern is to clearly document if you're doing some form of stateful lazy evaluation that may warrant the client caching the result on their own (using ToArray(), for instance.)