Общие правила обозначения имен параметров для Java (с несколькими символами)?

В некоторых интерфейсах, которые я написал, я хотел бы назвать общий тип типа более чем одним символом, чтобы сделать код более удобочитаемым.

Что-то вроде....

Map<Key,Value>

Вместо этого...

Map<K,V>

Но когда дело доходит до методов, параметры типа выглядят как java-классы, которые также запутывают.

public void put(Key key, Value value)

Кажется, что Key и Value являются классами. Я нашел или подумал о некоторых обозначениях, но ничего подобного конвенции от солнца или общей передовой практики.

Альтернативы, которые я оценил или нашел...

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

Ответ 1

Oracle рекомендует следующее в Учебники по Java > Общие > Общие типы:

Типовые обозначения именования

По соглашению введите имена параметров, которые являются одиночными, заглавными буквами. Это резко контрастирует с условными соглашениями naming, о которых вы уже знаете, и с полным основанием: без этого соглашения было бы сложно чтобы определить разницу между переменной типа и обычным классом или именем интерфейса.

Наиболее часто используемые имена параметров типа:

  • E - Element (широко используется структурой коллекций Java)
  • K - Key
  • N - номер
  • T - Тип
  • V - Значение
  • S, U, V и т.д. - 2-й, 3-й, 4-й типы

Вы увидите, что эти имена используются в API Java SE и в остальной части этого урока.

Я придерживаюсь этого, чтобы избежать путаницы среди разработчиков и возможных сопровождающих.

Ответ 2

Добавить Type

Хорошее обсуждение можно найти в комментариях на странице DZone, Соглашения об именах для параметризованных типов.

См. комментарий Эрвина Мюллера. Его предложение имеет для меня совершенно очевидный смысл: Добавить слово Type.

Позвоните в яблоко яблоко, автомобиль автомобиль. Имя, о котором идет речь, - это имя типа данных, правильно? (В OOP класс по существу определяет новый тип данных.) Поэтому назовите его "Тип".

Пример Muellers, взятый из оригинальной статьи статей:

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

Добавить T

Повторяющийся вопрос предоставляет этот ответ Энди Томасом. Обратите внимание на выдержку из руководства по стилю Googles, в которой предполагается, что имя типа с несколькими символами должно заканчиваться в одном верхнем регистре T.

Ответ 3

Вы можете использовать javadoc, чтобы хотя бы дать пользователям своего общего класса ключ. Мне все еще не нравится (я согласен с @chaper29), но документы помогают.

например,

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

}

Другое, что мне известно, это использование моей IDE для реорганизации класса, нарушающего соглашение. Затем работайте над кодом и рефакторируйтесь на отдельные буквы. В любом случае мне становится легче, если используются многие параметры типа.

Ответ 4

Причина, по которой официальное соглашение об именах рекомендует использовать одну букву:

Без этого соглашения было бы трудно сказать разницу между переменной типа и обычным классом или именем интерфейса.

Я думаю, что с современными IDE эта причина больше недействительна, например. IntelliJ Idea показывает общие параметры типа с разными цветами, чем обычные классы.

Код с общим типом, отображаемым в IntelliJ Idea 2016.1 Код с общим типом, отображаемым в IntelliJ Idea 2016.1

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

Примечание. Поскольку я не являюсь пользователем Eclipse или Netbeans, я не знаю, предлагают ли они аналогичную функцию.

Ответ 5

Да, вы можете использовать многосимвольные имена для переменных типа, если они явно отличаются от имен классов.

Это отличается от конвенции, предложенной Sun с введением дженериков в 2004 году. Однако:

  • Существует более одного соглашения.
  • Многосимвольные имена согласуются с другими стилями Java, такими как стиль Google для Java.
  • Читаемые имена (удивление!) более читабельны.

читаемость

В некоторых интерфейсах я написал Id, чтобы назвать параметр generic type более чем одним символом, чтобы сделать код более удобочитаемым.

Считываемость - это хорошо.

Для сравнения:

    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> {

или, с многосимвольным соглашением Googles:

    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 Введите имена переменных переменных

Каждая переменная типа указана в одном из двух стилей:

  • Единая заглавная буква, необязательно сопровождаемая одной цифрой (например, E, T, X, T2)

  • Имя в форме, используемой для классов (см. раздел 5.2.2, имена классов), за которым следует заглавная буква T (примеры: RequestT, FooBarT).

Вопросы

"Без этого соглашения было бы трудно определить разницу между переменной типа и обычным именем класса или интерфейса". - из Учебники Oracle, "Общие типы"

Односимвольные имена - это не единственный способ отличить параметры типа от имен классов, как мы видели выше.

Почему бы просто не документировать значение параметра типа в JavaDoc?

Справедливо, что элементы @param JavaDoc могут предоставить более длинное описание. Но также верно, что JavaDocs не обязательно видны. (Например, theres помогает в Eclipse, который показывает имена параметров типа.)

Имена параметров многосимвольного типа не следуют соглашениям Oracle!

Многие традиционные соглашения Suns почти повсеместно применяются в Java-программировании.

Однако это конкретное соглашение не является.

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