Naming generic type parameters...

There's been quite a discussion going on on the MSDN feedback site over the naming of generic type parameters.

If you look at the definition of the generic collections classes, you'll see things like:

List<T>
Dictionary<K, V>

What's up with those T's, K's, and V's?

If you look at our beta1 library design guidelines (can't find a published link right now) that suggests that you use single-character names for type parameters rather than longer, more descriptive names. But those guidelines weren't always there. In fact, before we had them, you might see a class like:

class Dictionary<Key, Value>
{}

which seems reasonable enough. But one day, you're browsing code, and you look at a method:

public void Process(Key k)
{
    // code here...
}

What's Key? It looks like it's a type, and unless you know that there's a type parameter named “Key“, you're likely to be confused for a while. We therefore decided to use the single-character naming approach, and my experience is that it's worked pretty well.

When you're working on a generic class, you normally have a small number of generic type parameters, and therefore it's not that hard to keep them straight. When you're using them, C# intellisense is nice enough to give you a description for the type parameter so you remember what it is.

That is, it's nice enough to do that if you remember to *write* the description using the <typeparam> tag. The IDE will add this tag automatically when you type the /// before your generic class definition.

Unfortunately, the beta1 drop doesn't have these descriptions for the built-in collection classes, so you don't get any help right now if you type “List<“. We'll be fixing that.