What are the type parameter naming guidelines?

I fetched the .NET Framework 4.6 source code from http://referencesource.microsoft.com/dotnet46.zip. Extracted it and processed the data to extract the generic parameter name from all generic class declarations.

Note: I only extracted the generic parameter name from generic classes with only one generic parameter. So this does not take into consideration the generic classes with multiple generic parameters.

grep -nohrP "class \w+<T\w*>" | sed -e 's/.*\<//' -e 's/>//' | sort | uniq -cd | sort -bgr

Result:

361 T
 74 TChannel
 51 TKey
 33 TResult
 30 TSource
 28 T_Identifier
 18 TElement
 12 TEntity
 11 TInputOutput
  7 TItem
  6 TLeftKey
  6 TFilterData
  5 T_Query
  4 T_Tile
  4 TInput
  3 TValue
  3 TRow
  3 TOutput
  3 TEventArgs
  3 TDataReader
  3 T1
  2 TWrapper
  2 TVertex
  2 TValidationResult
  2 TSyndicationItem
  2 TSyndicationFeed
  2 TServiceType
  2 TServiceModelExtensionElement
  2 TResultType
  2 TMessage
  2 TLocationValue
  2 TInnerChannel
  2 TextElementType
  2 TException
  2 TEnum
  2 TDuplexChannel
  2 TDelegate
  2 TData
  2 TContract
  2 TConfigurationElement
  2 TBinder
  2 TAttribute

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

I've looked at all the answers so far, and I think they're all partially right, but don't fully consider all situations.

My view is that naming should always add contextual value. So, naming a type parameter TEntity because its type constraint is IEntity would not necessarily add value, especially as IntelliSense would indicate its type anyway. The name should reflect the type parameter's functional role. But this is not to say it shouldn't be done if no other descriptive name is appropriate (and a single letter wouldn't be self-explanatory).

In the case of one type parameter, the context should normally be obvious in terms of the class, so T is fine. For multiple type parameters, add a descriptive context to each such as TKey and TValue - another reason the types shouldn't be used in case multiple type parameters are the same type (resulting in TEntity1 and TEntity2 which adds little value)?

So, my answer is similar to JaredPar and Tomas Aschan's answers, but with added qualification.

UPDATE 04/12/19: The Microsoft guidelines on type parameter naming are quite clear on the naming conventions. I've therefore modified my answer to reflect this, and removed the paragraph where I said it is acceptable to use T, U, etc. or T1, T2, etc. From the guidelines, single letters should only be used where there is a single type parameter (if self-explanatory). Always use descriptive names for multiple type parameters.

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.