What are the type parameter naming guidelines?

问题

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>
{


}

public class EntityCollection<TEntity>
{


}

How do you decide which name to use?

Thanks

回答1:

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

回答2:

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

回答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.

回答4:

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

How many type arguments are there?
Are there any constraints on them?
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...):

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.
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.
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.

回答5:

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).

回答6:

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.

回答7:

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.

来源：https://stackoverflow.com/questions/770908/what-are-the-type-parameter-naming-guidelines

标签

.net

generics

naming-conventions