.NET Collection Naming Convention

Question

My colleague and I have been having a discussion about what Collections should be called.

For example:

Class Product - Collection - Class Products

or

Class Product - Collection - Class ProductCollection

I've had a look around to see if I can see any guidelines or reasons for using one or the other but nothing seems to spring out. The framework seems to use both variants for example. The argument I can see is that a class that has a collection of products variable should be called Products but it should be of type ProductCollection.

Which is correct if any?

In the same vane is there a standard for the naming of return variable for a function. e.g. retVal?

We mainly code in C#, although I'm not sure that affects my question.

Answer 1

I would say that with generics there should rarely ever be a reason to create a custom collection type. But if you must I would say that ProductCollection would best fit the naming conventions of the framework.

Still, consider using a List<Product> or Collection<Product> or better yet IList<Product> or ICollection<Product>.

Edit: This is in response to MrEdmundo's comments below.

In your case you have two choices. The most obvious choice would be to use inheritance like this:

class Ball { }

class BallCollection : List<Ball>
{
    public String Color { get; set; }
    public String Material { get; set; }
}

I say obvious because it seems like the best idea at first glance but after a bit of thought it becomes clear that this is not the best choice. What if you or Microsoft creates a new SuperAwesomeList<T> and you want to use that to improve the performance of your BallCollection class? It would be difficult because you are tied to the List<T> class through inheritance and changing the base class would potentially break any code that uses BallCollection as a List<T>.

So what is the better solution? I would recommend that in this case you would be better off to favor composition over inheritance. So what would a composition-based solution look like?

class Ball { }

class BallCollection
{
    public String Color { get; set; }
    public String Material { get; set; }
    public IList<Ball> Balls { get; set; }
}

Notice that I have declared the Balls property to be of type IList<T>. This means that you are free to implement the property using whatever type you wish as long as that type implements IList<T>. This means that you can freely use a SuperAwesomeList<T> at any point which makes this type significantly more scalable and much less painful to maintain.

Answer 2

Products is certainly not correct IMHO. A non-static class name should represent a noun (not plural), because you should be able to say "x is a [classname]".

Obviously, Products doesn't fit in that scheme. ProductCollection does:

Illustration:

var products = new Products(); // products is a Products

var products = new ProductCollection(); // products is a ProductCollection

Which one "sounds right" ?

Another thing about naming collection classes: I usually try to name collection classes in such way that it is clear what kind of collection it is.

For example:

• class ProductCollection: can only be enumerated and the Count retrieved (i.e. only implements ICollection interface(s))
• class ProductList: a list that can be manipulated using Add(), Insert(), etc. (i.e. implements IList interface(s))
• class ProductDictionary: a dictionary of products accessible by some key (i.e. implements IDictionary interface(s))

The last one can be ambiguous if there could be a doubt what the key of the dictionary is, so it's better to specify what the key type is (like ProductDictionaryByString). But to be honest, I rarely name it this way because most of the time the key will be a string anyway.