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?

  • 3
    This is not a constructive question. It will only get answers with the poster's favorite style. – Michael K Jul 20 '11 at 15:04
  • 1
    Have a look at constraints, considering your example : msdn.microsoft.com/en-us/library/d5x73970.aspx#Y426 – Matthieu Jul 20 '11 at 15:06
  • 2
    @Michael there will be a number of answers, and the accepted answer will be Robert's favourite, but various other answers will get voted up. – StuperUser Jul 20 '11 at 15:11
  • 5
    @Michael A subjective question gets a subjective answer. The question is still constructive because it serves as a reference point for anyone wanting a variety of ideas/solutions to this particular problem. The one I mark as the answer doesn't represent the one and only useful bit of information. – void.pointer Jul 20 '11 at 15:19
  • Perhaps turn it into a community wiki, as a good, although subjective, resource? – tylermac Jul 20 '11 at 17:45

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>
| improve this answer | |
  • 2
    I don’t find this subjective at all. i and T work, and this is measurable in principle (i.e. it’s measurable whether comprehension of source code increases if, say, loop indices get different identifiers). Just because it’s hard to measure doesn’t mean we have to tag the “subjective” label on everything. Given the wide use without obvious problems, it’s quite reasonable to say even without measuring that this does in fact work. – Konrad Rudolph Jul 20 '11 at 16:01
  • 2
    @Konrad: You've a point . . . however the question isn't tagged as subjective, the asker admits it's a subjective topic supposing that folks tend to have their own preferences on naming conventions. So while the question may not be subjective (and as a matter of fact it isn't as there is a correct answer i.e. the answer that links to the Microsoft official guideline) the topic is subjective, as I'm sure someone will post an "i and T are evil. One must never use single letter names ever" type answer. Have added an ish to help satisify everyone :) – Binary Worrier Jul 20 '11 at 16:27
  • 1
    I think the comments alone added to this post make it a very valuable response, although the answer itself is very helpful. T makes sense when we're talking about a type with no constraints, TFruit makes sense because it says to me "Any type with the constraint that it is a fruit". This seems like a good "rule of thumb" for naming generic type parameters. Thanks!! – void.pointer Jul 20 '11 at 17:03
  • 1
    Just to note, this aligns with the .NET Framework Design Guidelines for Library developers from MSDN. See: Names of Generic Type Parameters. – Grant Thomas Jul 20 '11 at 17:18

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.

| improve this answer | |

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.

| improve this answer | |
  • Use of T prefix for type parameters and I for interface names is explicitly required ("DO ..." rules) in the Framework Design Guidelines. – Richard Jul 20 '11 at 15:48
  • 1
    It’s questionable what using TFruit here brings to the table over T. Using name such as TType or TypeT is certainly nonsense. It adds no information whatsoever over just T. The exact same information is conveyed. – Konrad Rudolph Jul 20 '11 at 16:03
  • @Konrad Rudolph: Look closely at my example of TypeT, it covers a special case when dealing with System.Type. I do think my names have a higher entropy than just using T for the type, especially if the generic is also constrained. – Falcon Jul 20 '11 at 17:06

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.

| improve this answer | |

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.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.