Naming convention for type parameters

It looks like Kotlin is sticking with the Java naming conventions for type parameters: T, K for keys, V for values and so on. But this convention doesn’t make much sense in general. K and V looks like a good idea at first, but how fits T into the picture? I guess T stands for “type”, but K and V are type parameters as well. It get’s completely absurd when we have some more type parameters not beeing one of the predefined kinds (like “key”), then you would continue with U , V

I suggest to establish the Scala naming convention starting with A. It is simpler and avoids strange things like V for “Value” and V as successor of T.

1 Like

I don’t see anything strange with the Java conventions. Using “Key” instead of “K” is confusing because it looks like a class. And starting alphabetically from A is certainly worse than using abbreviations that make sense (K = Key, V = Value, E = Enum or Element, T = usually any type for containers). Also, Java uses List<E> for example while Kotlin uses List<T> which is clearer in my opinion.

1 Like

I have been using full names in in my own Java classes for quite some time (KEY or VALUE). Works like a charm.

1 Like

In cases when I feel that a single letter name is not enough for a type parameter and I need a more descriptive name, I use names like “TKey”, “TSomething”. The “T” at the start helps to understand that it’s not a concrete type but a type parameter.

1 Like

Here’s an article about this topic: Break the Java Generics Naming Convention?