Имена параметров универсального типа обычно содержат один, один заглавный символ. Если вы начинаете читать официальную документацию ORACLE по дженерикам, первый пример

/**
 * Generic version of the Box class.
 * @param <T> the type of the value being boxed
 */
public class Box<T> {
    // T stands for "Type"
    private T t;
 
    public void set(T t) { this.t = t; }
    public T get() { return t; }
}

Название универсального типа — T. Одна отдельная буква, не слишком значимая и обычно не совпадающая с другими стилями именования идентификаторов. Он широко используется только для генериков. Странный. В чем причина этого?

Вот аргументы, которые я слышал до сих пор:

• Классу или методу не нужно много имен переменных типов, поэтому у вас не останется букв ABC.
  • Исходя из этого рассуждения, мы также должны использовать имена односимвольных методов? В классе не должно быть слишком много методов, поэтому мы также не исчерпаем алфавит.
• Не проблема в том, что один символ по сути не объясняет тип, поскольку существует JavaDoc. Вы можете объяснить, что на самом деле означает имя типа.
  • И мы должны также забыть все, что мы узнали о чистом коде и именовании переменных. Структура кода определяет, что делает код, и, поскольку это то, чем он является на самом деле, структура кода является современной. Именования (переменные, методы и т. Д.) Обычно следуют за изменением структуры кода, поскольку наименование помогает программисту. Хотя именование во многих случаях устарело, особенно в случае логических переменных. Во многих случаях это говорит о том, что является истинным значением. JavaDoc поддерживается и исправляется через некоторое время после того, как код и модульные тесты завершены, отлажены и отлажены. На практике «некоторое время спустя» означает: никогда. JavaDoc устарел, недоступен при чтении кода так же быстро, как само имя, поэтому он должен содержать информацию, которую вы не можете включить в структуру кода и присвоение имен. Почему имена типов будут исключением?
• Имена типов, содержащие один символ, делают их отличимыми от имен переменных, методов и классов, а также имен констант.
  • Это хороший момент. Имена типов должны отличаться от имен переменных, методов и классов. Но я не вижу сильной стороны, почему мы должны использовать разные имена для констант. Там нет места, где вы могли бы использовать константу и тип или где это действительно могло бы сбить с толку. Они используются в совершенно разных местах, в разных синтаксических позициях. Если это такая большая боль в осле, почему мы не страдаем от этого в случае имен методов и переменных? За именами методов следуют символы () в Java? Больше нет, когда мы доберемся до Java 8!
• Но  Google Code Style  позволяет использовать имена из нескольких символов.
  • О да. И это говорит о том, что если вы используете многосимвольные имена типов, имя должно иметь T-постфикс, например, RequestT, FooBarT. Должен ли я также префикс строковых переменных с буквами sz и целыми числами с i, как в  венгерской нотации ?

Что тогда?

Если вам не нравится именование отдельных символов для шаблонов, вы можете назвать их с префиксом _ или $. Это предложение, которое вы можете увидеть на  stackoverflow . Что касается меня: это странно. Использование $ делает «heimlich» теплым чувством, напоминающим мне о моей юности, когда я программировал на Perl. Я не делаю этого больше и по уважительным причинам. Времена изменились, технологии изменились, я изменился.

$ Обычно используется компилятором и некоторыми генераторами кода для именования сгенерированных полей и методов. Использование $ на уровне исходного кода Java может вызвать определенные трудности для компилятора при поиске подходящего имени в случае коллизии имен, но текущая версия компиляторов Java довольно подвержена ошибкам в этом отношении. Они просто пытаются найти подходящее имя с помощью некоторого простого алгоритма, пока не найдут имя, которое не конфликтует с каким-либо именем исходного кода Java, поэтому это не будет проблемой.

Подчеркивание : ну, это действительно то, что мы использовали в старые времена вместо пространства. На старых матричных принтерах символ подчеркивания печатался настолько плохо, что вы не могли отличить его от пробела, и, таким образом, это было уродливым приемом, состоящим из нескольких имен переменных. Из-за этого подчеркивания в начале названия находится полный анти-паттерн imho, практически именующий две вещи с использованием одного и того же имени. Это почти как если бы символа подчеркивания вообще не было.

Вы также можете использовать префикс T_, поскольку это соглашение в C ++ и в C # (я не слишком знаком с этим, я не уверен в этом). Но это так же безобразно, как и без Т.

Мой вкус — использовать значимые имена с теми же соглашениями, которые мы применяем в случае констант. Например использовать

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

вместо

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

Хотя это мое личное, старшее, профессиональное, экспертное мнение, я им не пользуюсь. Зачем? Потому что я работаю в корпоративной среде в команде. Выигрыш от использования чего-то более удобочитаемого, чем официальный дефолт, не так высок, как ущерб от споров и разногласий. В дополнение к этому новые сотрудники должны привыкнуть к местному стилю, и это также стоит денег. Использование удобного, но не оптимального глобального стиля лучше, чем использование хорошего локального стиля. Живи с этим.

Можем ли мы выйти на мировой уровень?

Можешь попробовать. Это самое большее, что я могу сказать. Было бы лучше, если бы исходное предложение, устанавливающее стандарт кодирования, было лучше, чем стиль одной буквы 1960-х годов, но это уже история. Ущерб был нанесен. И это не сравнимо с ущербом, вызванным блестящей идеей введения нуля в ОО.

Мы будем жить с односимвольными обобщениями, пока жива Java. А поскольку мне почти 50 лет, это будет более продолжительный период, чем моя жизнь. Обратите внимание, что КОБОЛ все еще жив. Мы не должны ожидать ничего меньшего от Java.