一部のインターフェイスでは、コードを読みやすくするために、ジェネリック型パラメーターに複数の文字を使用して名前を付けたいと思っています。

何かのようなもの....

Map<Key,Value>

これの代わりに...

Map<K,V>

しかし、メソッドに関しては、型パラメーターはjava-classesのように見え、これも混乱を招きます。

public void put(Key key, Value value)

KeyとValueはクラスのようです。私はいくつかの表記法を見つけたり、考えたりしましたが、Sunの慣習や一般的なベストプラクティスのようなものはありませんでした。

私が推測または見つけた代替案...

Map<KEY,VALUE>
Map<TKey,TValue>

Javaチュートリアル> Generics> Generic Typesでは、以下をお勧めします。

タイプパラメータの命名規則

慣例により、型パラメーター名は単一の大文字です。これは、すでに知っている変数の命名規則とはかなり対照的であり、正当な理由があります。この規則がないと、型変数と通常のクラスまたはインターフェース名の違いを区別するのが難しくなります。

最も一般的に使用されるタイプパラメータ名は次のとおりです。

• E-要素（Javaコレクションフレームワークで広く使用されています）
• K-キー
• N-番号
• T-タイプ
• V-値
• S、U、Vなど-2番目、3番目、4番目のタイプ

これらの名前は、Java SE APIおよびこのレッスンの残りの部分で使用されています。

開発者と考えられるメンテナーの間の混乱を避けるために、私はそれに固執します。

追加 Type

良い議論は、DZoneページのコメント、パラメータ化された型の命名規則で見つけることができます。

Erwin Muellerのコメントを参照してください。彼の提案は私には完全に明白です。単語を追加しますType。

リンゴをリンゴ、車を車と呼びます。問題の名前はデータ型の名前ですよね？（OOPでは、クラスは基本的に新しいデータ型を定義します。）それを「タイプ」と呼びます。

元の投稿の記事から引用したミュラーの例：

public interface ResourceAccessor < ResourceType , ArgumentType , ResultType > {
    public ResultType run ( ResourceType resource , ArgumentType argument );
}

追加 T

質問を複製すると、Andy Thomasによるこの回答が提供されます。複数文字のタイプ名は単一の大文字で終わる必要があることを示唆するGoogleのスタイルガイドの抜粋に注意してくださいT。

正式な命名規則が単一文字の使用を推奨する理由は次のとおりです。

この規則がないと、型変数と通常のクラスまたはインターフェース名の違いを区別するのが難しくなります。

最近のIDEでは、その理由は、たとえば、もはや有効ではないと思います。IntelliJ Ideaは、通常のクラスとは異なる色でジェネリック型パラメーターを示しています。

IntelliJ Idea 2016.1に表示されているジェネリック型のコード

その違いのために、私は通常の型と同じ規則で、ジェネリック型に対してより長い説明的な名前を使用します。TやTypeなどの接頭辞や接尾辞は、不要なノイズであり、ジェネリック型を視覚的に区別する必要がなくなったと考えるため、追加しません。

注：私はEclipseまたはNetbeansのユーザーではないため、同様の機能を提供しているかどうかはわかりません。

はい、クラス名と明確に区​​別されている限り、タイプ変数には複数文字の名前を使用できます。

これは、2004年にジェネリックが導入されたことでSunが提案した規則とは異なります。

• 複数の規約が存在します。
• 複数文字の名前は、Googleの Java用スタイルなど、他のJavaスタイルと一致しています。
• 読みやすい名前は（驚き！）より読みやすくなっています。

読みやすさ

一部のインターフェイスでは、コードを読みやすくするために、ジェネリック型パラメーターに複数の文字を指定したいと思っています。

読みやすさは良いです。

比較：

    public final class EventProducer<L extends IEventListener<E>,E> 
            implements IEventProducer<L,E> {

に：

    public final class EventProducer<LISTENER extends IEventListener<EVENT>,EVENT> 
           implements IEventProducer<LISTENER, EVENT> {

または、Googleの複数文字の規則を使用：

    public final class EventProducer<ListenerT extends IEventListener<EventT>,EventT> 
           implements IEventProducer<ListenerT, EventT> {

    public final class EventProducer<ListenerT extends IEventListener<EventT>,EventT> 
           implements IEventProducer<ListenerT, EventT> {

Googleスタイル

GoogleのJavaのスタイルガイドでは、単一文字の名前や複数文字のクラスのようなT.で終わる名前の両方が可能

5.2.8タイプ変数名

各型変数は、次の2つのスタイルのいずれかで名前が付けられます。

• 必要に応じて（例えば、単一の数字に続く単一の大文字、E、T、X、T2）

• クラスに使用される形式の名前（セクション5.2.2、クラス名を参照）、それに続く大文字のT（例：RequestT、FooBarT）。

問題

「この規則がないと、型変数と通常のクラスまたはインターフェース名の違いを見分けるのは難しいでしょう。」– Oracleチュートリアルの「ジェネリック型」

上で見たように、1文字の名前は、型パラメーターとクラス名を区別する唯一の方法ではありません。

JavaDocで型パラメーターの意味を文書化しないのはなぜですか？

@paramJavaDoc要素がより長い説明を提供できることは事実です。しかし、JavaDocsが必ずしも表示されているとは限らないことも事実です。（たとえば、タイプパラメーター名を表示するEclipseのコンテンツアシストがあります。）

複数文字タイプのパラメーター名は、Oracleの規則に従っていません！

Sunの元の規則の多くは、Javaプログラミングでほぼ普遍的に使用されています。

ただし、この特定の規則はそうではありません。

競合する慣習の中からの最良の選択は意見の問題です。この場合、Oracle以外の規則を選択した場合の影響は軽微です。あなたとあなたのチームはあなたのニーズに最も合う大会を選ぶことができます。

javadocを使用して、少なくともジェネリッククラスのユーザーに手掛かりを与えることができます。まだ気に入らない（@ chaper29に同意する）が、ドキュメントは役立ちます。

例えば、

/**
 * 
 * @param <R> - row
 * @param <C> - column
 * @param <E> - cell element
 */
public class GenericTable<R, C, E> {

}

もう1つ知っていることは、IDEを使用して、規則に違反するクラスをリファクタリングすることです。次に、コードに取り組み、1文字にリファクタリングします。とにかく、多くの型パラメーターが使用されている場合、私にとっては簡単になります。