.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

Answer 1

Thesaurus.com

Look no further. No longer will you mull over pluralized singularity. Just fasten one of these plural-protectors to your object's name:

• Jumble
• Gob
• Trove
• Miscellany
• Vocab
• Load
• Agglomeration
• Mound
• Series
• Lexicon
• Muster
• Glossary
• Hoard
• Swarm
• Group
• Cluster
• Convoy
• Assemblage
• Herd
• Mob
• Batch
• Amassment
• Pile
• Bank
• Congregation
• Clump
• Volume
• Set
• Reserve
• Compilation
• Flock
• Army

Make it fun.

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.

Answer 3

The .NET Framework frequently uses a "Collection" postfix for its collection types. StringCollection, ObservableCollection, KeyedCollection, etc. So go with ProductCollection.

Answer 4

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 5

Noticed nobody answered you on the retVal stuff (Or I could just be getting blind). Although I'm not an expert; on the matter of the retVal issue I'm not 100% sure what you mean by "naming of return variable", but if you mean stuff like this:

public void GetSomething(out object retVal) 
{
    retVal = ThingFactory.CreateSomething();
}

I would say, no matter what the convention is, don't do it. It's very annoying. Just return the value instead. If you need to return more than one thing, then I would think the method either does more than one thing (which a method shouldn't) or those things should be wrapped up in some sort of logical class that could be returned instead.

If instead by "naming of return variable" you mean stuff like this:

var retVal = ThingFactory.CreateSomething();

Then I would say name the variable according to what it is. What it is going to be used for. If its a list of cars, call it listOfCars, if it's a piece of bread to be eaten later, call it pieceOfBread or pieceOfBreadToBeEatenLater.

Hope that helped and that it wasn't too far off into a field somewhere :p