What are the type parameter naming guidelines?

Question

I noticed, as well as saw in the Essential C# 3.0 book, that paramters are usually defined as T or TEntity

For example:

public class Stack<T>
{


}

or

public class EntityCollection<TEntity>
{


}

How do you decide which name to use?

Thanks

Answer 1

I'm not aware of any solid conventions for generics really.

The samples that I have seen though use one of the ff variations:

• T for single type parameters
• K for a second type parameter, U for a third, e.g., SomeGeneric<T, K, U>
• T and a number for a second and third type parameter, e.g., SomeGeneric<T1, T2, T3>

I guess generics are new enough that common industry conventions haven't been established yet.

Answer 2

Here is my set of rules

• If there is one parameter, I name it T
• If there is more than one parameter, I pick a meaningful name and prefix with T. For example TKey, TValue

For a semi-official opinion, it's worth looking at the framework design guidelines on the subject:

• http://blogs.msdn.com/brada/archive/2005/12/02/497340.aspx

Answer 3

In the end, it doesn't REALLY matter. Use a naming convention that makes sense.

public class MyDictionary<T1, T2>
{ }

is probably not as useful as

public class MyDictionary<KeyType, ValueType>

(or TKey, TValue, if you prefer).

If I'm looking at your implementation and have to think "ok, what is this 'T3' thing again?" then you didn't do a good job.

Answer 4

Example from Microsoft:

public interface IDictionary<TKey, TValue>

The type parameter represents something, so if you want to have readable code, this "something" should be obvious from the code (without extra comments). Using type names like T, V, U isn't necessarily obvious (but sometimes it can be).

Answer 5

There are a couple of things I think you should take into account:

1. How many type arguments are there?
2. Are there any constraints on them?
3. Are they used for something particular?

In general, I always prefix my type arguments with T, and make them "descriptive enough", meaning as descriptive as they need to be for me to understand what they do, and/or what is required of them, when I look at the code in six months.

A couple of examples of, in my opinion, good naming of type arguments (numbering in this list independent of numbering above...):

1. One argument, and it's obvious from the class name (or otherwise from the context in the code) why the type name is needed:

   List<T>
   

   Since we can see that this is a list of objects of type T, and there are no specific constraints on T, there is no need to give a more specific name to the type argument.

2. Several arguments, that represent different things in the generic class/interface:

   IDictionary<TKey, TValue>
   

   We need to be able to distinguish between the two arguments, so we don't supply the key type for value and vice versa. Thus, naming the arguments Key and Value, and prefixing with T, seems appropriate.
   I must emphasize that this is a much better practice than for example IDictionary<T1, T2> or IDictionary<T, U>, since in the latter two cases there is no way to intuitively know which argument will be used for what.

3. One type argument, but the type must fulfill some requirements or other:

   Repository<TEntity> where TEntity : class, IEntity
   

   Since we require that the type implements another interface, it makes sense to give some heads-up to the programmer that this is the case. Choose some informative name that helps you see what is required of the type, and prefix it with T.