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