There’s been a bit of a firefight going on within Microsoft about what naming conventions to use for the type params of generic types. The debate has spilled out into the streets with this post to the Microsoft Product Feedback Center. Some of the suggestions made in that public discussion are well intended, but C#-centric and absolutely the wrong solution for .NET as a whole.
The defacto convention Microsoft is using is to use single capital letters for the type params: Foo<T> for example, indicates the generic type Foo accepts a single type as a parameter. That T becomes an identifier within the scope of the Foo class definition, much like a nested type. You can use T when defining methods, such as function Bark<T>.
Since the param identifier is a name within the scope of the class, it’s very important that it not collide with other type names that are commonly used in class declarations.
Microsoft’s Anthony Moore’s justification for the single letter convention is pretty simple: It’s easy to say in conversation, it’s easy and compact to type (the params are part of the generic type’s signature so you’ll be typing them a lot), easy to recognize at a glance when looking at the Foo type declaration, and most of all, unlikely to conflict with other types declared or used within the Foo class.
The arguments against the single letter convention are many and varied. The strongest argument against is that single letters don’t convey much information to a reader considering using the generic type. In a type like Dictionary<K,V>, what are K and V used for? You’ll probably have to pause for a moment to guess that K and V represent the types of a Key / Value pair relationship. Dictionary<Key, Value> would be much clearer to the user of the Dictionary type, but would present difficulties for the author of the Dictionary type because Key and Value could no longer be used as names of properties, fields, methods, or parameter names within the Dictionary type.
With Dictionary<Key, Value> it would also be more difficult to recognize which parts of the generic class are generic and which are concrete, since the generic params look like normal concrete types. Compare “property Item: V” with “property Item: Value”.
A couple of the comments on the MS suggestion thread suggest using all caps as a way to distinguish between normal types and generic param types in a generic class: Dictionary<KEY, ITEM> with members like “property Item: VALUE”.
This is absolutely the wrong solution for .NET. .NET metadata is case preserving, but not case sensitive. VALUE and Value and value will conflict with each other if they are in the same scope in IL metadata.
You’ll notice I’m not making a language war out of this. I’m not accusing anyone of myopic C++/C# bigotry or extolling the virtues of Pascal/Delphi case insensitivity. That would be too easy. ;>
Incidentally, similar arguments about generic param naming conventions have come up several times in the ECMA CLI standards committee discussions. The committee presented its concerns to the Microsoft dev team and Microsoft was very open to discussing the issues. Ultimately, I think the single cap letter will continue to be the defacto convention.
Thanks to David Berneda for pointing out the firefight thread in his TeeChart blog.