Type Parameter Naming
C, ... are minimal and intuitive names for type parameters.
A generic type has a certain number of type parameters. In C#, a programmer must give names to each type parameter in some order. Descriptive names are typically best, but sometimes a single letter name is completely self explanatory. In this case, there are multiple naming conventions in use. Let's state some of them and then list their pros and cons.
Microsoft has guidelines for naming type parameters. I briefly repeat them here for convenience.
It is idiomatic in C# for type parameter names to start with
T. Such names are consistent with these guidelines.
This post is about the case in which
The length of a name should be related to the length of the scope. You can use very short variable names for tiny scopes, but for big scopes you should use longer names.
Like all instances of the naming optimization problem, the type parameter names must be unique because they are in the same scope. An additional constraint imposed by C# is that each name must be a legal identifier. Roughly speaking, a legal identifier starts with an underscore (
_) or a letter and then may have additional underscores (
_), letters, and numbers.
Below I give three conventions for naming type parameters. I created names for each of them. If any convention already has a name, then I would love to hear about it.
This convention begins each name with
T and then finishes with the next natural number. A good example of this convention is the multi-parameter versions of
Func. The variant with 17 type parameters is shown above in the feature image.
Tis somewhat redundant. When every name in a scope starts with
T, then none of them should. It could be that
Twas only included because the identifier is not legal without it.
With these type parameter names, I would be least surprised to see
t3, ... as the variable names. They have the same advantages and disadvantages as the type parameter names. In the
Func example, the variables are named
arg3, ..., which increases the amount of redundant information.
This convention selects
T as the name of the first type parameter and then continues alphabetically using the letters after
T. I have only seen this convention used in proprietary code. I have also seen alternatives that start with
S instead of
S, it is unclear if the index of
2. Beyond that, I do not know the index of
Xbecause I do not intuitively know how far
Xis away from
With these type parameter names, the variable names that I have see are their lowercase equivalents. That would be
v, ... when starting from
t. They have the same advantages and disadvantages as the type parameter names.
This convention selects
A as the name of the first type parameter and then continues alphabetically using the letters after
A. I first encountered this convention in
language-ext. Here is an example of me standardizing a file to use this convention.
With these type parameter names, the variable names that I have seen are their lowercase equivalents. That would be
c, ..., and they have the same advantages and disadvantages as the type parameter names.
I prefer the alphabetic convention. I think it has the best tradeoffs. Since the scope is small, it is clear from context that these are all names of type parameters. Beginning each name with
T is completely redundant.
When the only thing known about a set of type parameters is their order and quantity, then naming them alphabetically starting with
C, ... minimizes noise while still intuitively communicating the order and quantity because of the natural correspondence between the alphabet and the natural numbers.
The feature image is from a screenshot I took of the documentation of
System.Func-17 in the .NET API.
This post was based on this post to my previous blog on 2019-01-19. I think this post is better.
The tags feature of Coding Blog Plugin is still being developed. Eventually the tags will link somewhere.