What's a good naming convention for generic types in C#? [closed]

Question

I decided to ask this question here instead of on stack overflow because it is rather subjective.

In C#, typically I see generic types with very poor names. Specifically, "T" is commonly used but is not a meaningful name by itself. For example:

class Fruit<T>
{
    T fruit;
}

While this is the typical approach, would anyone recommend against this? And if so, what would a reasonable naming convention be for generic types in the context of C# for generic functions and classes?

In my previous example, let's assume that generic type T must always be a type of fruit, such as Apple or Orange. The type T needs to make it obvious that it's a type of fruit, so maybe a better name would be FruitType, so we end up with:

class Fruit<FruitType>
{
    FruitType fruit;
}

This is just to give you guys an idea of what I'm looking for. What's an acceptable "rule of thumb" for this issue?

Answer 1

It is indeed subjective...ish.
As some folks find i is perfectly valid for a for loop variable, some think T is perfectly valid for a type place-holder in a generic class.

I personally espouse this approach, it's a common convention and people generally know what you mean.

Where the type is meaningful I'd use a meaningful name, but generally start it with T. I recently developed a generic dictionary class (don't ask) and the declaration was

public class Dictionary<TKey, TValue>

However, for something like a Tuple, where the types are essentially meaningless, I consider the following perfectly acceptable.

public class Tuple<T1, T2, T3>

Answer 2

Microsoft has an official guideline regarding generics : Names of Classes, Structs, and Interfaces (quoted here, and in book form : Framework Design Guidelines ).

Regarding your specific question it says :

Do name generic type parameters with descriptive names, unless a single-letter name is completely self explanatory and a descriptive name would not add value.

IDictionary<TKey, TValue> 

is an example of an interface that follows this guideline.

Consider using the letter T as the type parameter name for types with one single-letter type parameter.

Do prefix descriptive type parameter names with the letter T.

Consider indicating constraints placed on a type parameter in the name of parameter. For example, a parameter constrained to ISession may be called TSession.

Answer 3

I think you're right, although T has become quite a standard. It probably originates from the old C++ times and the wording "of type T". I consider it a good practice to be as descriptive as possible, but that's subjective.

You could choose T as a prefix, much like many people choose I for interfaces. Thus

class Juice<TFruit> where TFruit...

would be a good name in my humble opinion. I prefer prefixes to suffixes in most cases, as it's immediatelly clear what you are seeing when you stumble upon it and it's easier to search for with things like Intellisense. It's good practice for UI-Controls, too, when you most likely always know the type (e.g. TextBox) but aren't 100% sure about the descriptive name you gave it.

The negative side of it is, that it looks bad when the type itself begins with T. So I think it'd be a good thing to suffix the generic type in special cases, like the one below.

class SomeAlgorithm<TypeT> where TypeT : Type

Please note that this is just my opinion and highly subjective. But I do think I've got a minor point with preferring prefixing to suffixing.

Answer 4

The whole point of generics is to delegate functionality - the generic class does one thing, its argument does another. The textbook example is a generic collection: the collection stores 'things', but it doesn't care what these things are. A generic name (sic!), thus, has a certain logic to it - we don't want it to be descriptive, because there is nothing to describe other than "it's the generic type argument", which the name T encompasses exhaustively (considering the convention). Being descriptive is good, but being overly descriptive suggests restrictions that aren't there.

Sometimes, however, a generic class or method has more than one type parameter, and at this point, it makes sense to give them more descriptive names, so that their role becomes obvious. A good example would be for a key-value collection type, where both key and value are generic; calling them T and S (or Q or whatever) would be less useful than calling them, say, KeyType and ValueType, or TKey and TVal.

Answer 5

The answer is indeed subjective. However, it does have merit as a question, as code should self-document, and we could possibly all learn some better ways to do it.

The following are the conventions I learned and follow:

• Generic type parameters should never be able to be mistaken for concrete classes. This generally encourages a preface of T regardless of whatever follows, much like interfaces are generally prefaced with I.

• A single generic type parameter on a class or method should usually be labelled T. This is near-universally-understood convention dating back to C++ templates.

• Multiple generic type parameters on the same class or method declaration should all start with T, but be differentiated by some concise but understandable means. TIn and TOut, for example, are common and well-understood GTPs for a method that accepts a strongly-typed generic input and produces a strongly-typed generic output.

• Multiple differentiated but unremarkable types, such as for a containing class like .Net's Tuple or delegate types like Func, Predicate and Action, can be labelled T1, T2, T3, etc. However, "remarkable" GTP declarations (having a definite purpose and/or very specific type restrictions) should have something more descriptive.

• A single generic type on a method, which differs from the generic type of a containing class, can either follow the previous rule regarding multiple types in a class or method, OR if the type is unremarkable other than being different it can be given a different single letter, often U or V. This is again convention dating back to C++ templates.

• Whatever you choose to do, keep it consistent; don't label a GTP for one class T, and the next TParam, unless the second class is nested in the first making T unavailable for use in the second.