Is something as simple as do the T, K and V parameterised types make sense versus mnemonics in Generics a hot item to talk about? You bet, people cannot seem to get enough of it
.The crux of the issue here is do T, K, V, etc in examples like List
- You can tell at a glance what each type parameter is used for.
- As with method parameters, so with type parameters: descriptive names are useful and helpful and mean you have to memorise less.
- To dispel the mistaken notion that a type parameter is simply a placeholder that doesn’t “mean anything”.
- Saying of List
: “it’s a list of some type T” may work, but other similar situations don’t work (e.g. Point ) - Even List
isn’t as simple as people think it is; “T” is never really OK. - T, V, K etc. may (just) be OK for native English speakers, but is not OK for those whose first language is not English.
- If you choose the first letter of each word as your type parameter name (e.g. K, V), what if two or more words start with the same letter ?
- Using descriptive names reduces the incidence of name clashing where two or more “T”s mix in the same lexical space.
- You don’t have to look up what “T” means virtually every single time you come back to use a generic class, and you don’t have to bear it mind while you’re using the class (and why should you ?).
- The case for using of single letters gets worse as more type parameters are added to generic classes in the future.
- Using “T” leads you to then use “U” (as in the Converter delegate). “T” may stand for Type, but “U” doesn’t stand for anything. So the single-letter convention is inconsistent as well as unhelpful.
- The brain isn’t overloaded having to remember what “T” and “U” stand for in more complex situations where generic types are mixed (e.g. in List
’s ConvertAll method).
I personally don’t particularly care, though given a choice, I prefer the <T,K,V> but that is probably because what I am use to seeing. We of course will know the outcome of this when Whidbey ships. :)