(Mainly gathered from comments)
To provide a more objective response, one could refer to documentation outlining the "TypeScript Type Parameter Naming Convention" and compare it with the Java Generics tutorial document that was linked.
The official stand of the TypeScript design team appears to be that they do not enforce any specific naming conventions on others. According to discussions on GitHub issues microsoft/TypeScript#6168 and microsoft/TypeScript#878, as articulated in this comment:
"[I]n general we're not interested in deciding stylistic things for people. Saying that there's One Approved Style for TS goes against our philosophy that we're here to provide types for JS regardless of how you're writing it (within reasonable parameters, of course 😉)."
ESLint's naming-convention
rule and TSLint's naming-convention
rule can potentially help enforce type parameter naming conventions through linting; however, these rules are typically not enforced by default.
In comparison, let's examine the relevant section from the Java Generics tutorial:
Type Parameter Naming Conventions
Conventional type parameter names consist of single uppercase letters to differentiate them from variable names. This practice serves to avoid confusion between type variables and regular class or interface names.
Commonly used type parameter names include:
- E - Element (commonly utilized in the Java Collections Framework)
- K - Key
- N - Number
- T - Type
- V - Value
- S,U,V etc. - Sequential types
These names are prevalent throughout the Java SE API and related lessons.
Note that the listed type parameter names are described as commonly used examples rather than strict mandates; they are descriptive rather than prescriptive.
The guideline suggesting the use of "single, uppercase letters" leans towards prescribing a convention to distinguish type names from variable names. However, it still reflects common practices rather than rigid rules.
One might conclude that an official or canonical type parameter naming convention does not exist in either TypeScript or Java, leaving any unofficial conventions subjective.
With regards to an unofficial convention within TypeScript, I personally perceive a trend toward using single uppercase characters that correspond to the represented entity. For instance:
T
for "type," a frequently employed generic name;
K
for "key" or P
for "property," usually when constrained by PropertyKey
or similar constructs;
V
for "value," often paired with K
for "key";
A
for "arguments" and R
for "return," aligning with function signatures like (...args: A) => R
;
N
for "number," S
for "string," B
for "boolean" when restricted by primitives;
These guidelines are flexible and subject to adaptation when clarity is paramount or potential ambiguity arises. In cases requiring multiple type parameters without collisions, modifications like appending numbers or prefixes may prove useful:
T0
, T1
, T2
, T3
, etc., to denote sequences of related types;
KT
, KU
, KV
for discriminative key prefixes;
While deviations exist, using brief UpperCamelCase names can offer more descriptive insights into types, although this approach risks confusion with specific types instead of type parameters:
Key
, Val
, Prop
, Arg
, Ret
, Type
, This
It's advisable to avoid certain unconventional practices unless justified by exceptional circumstances:
- Elaborate names resembling interface or class titles such as
InputType
or Properties
;
- Prepending an uppercase
T
to extended type names like TNotRecommended
;
- Initial lowercase letter beginnings like
t
, u
, or myType
;