This post originated from an RSS feed registered with .NET Buzz
by Eric Gunnerson.
Original Post: Naming generic type parameters...
Feed Title: Eric Gunnerson's C# Compendium
Feed URL: /msdnerror.htm?aspxerrorpath=/ericgu/Rss.aspx
Feed Description: Eric comments on C#, programming and dotnet in general, and the aerodynamic characteristics of the red-nosed flying squirrel of the Lesser Antilles
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.
Previous Topic
