Да, вы можете использовать многосимвольные имена для переменных типа, если они четко отличаются от имен классов.
Это отличается от соглашения, предложенного Sun с введением дженериков в 2004 году. Однако:
- Существует более одного соглашения.
- Многосимвольные имена соответствуют другим стилям Java, таким как Стиль Google для 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 style
Руководство по стилю Google Java допускает использование как однобуквенных, так и многосимвольных имен классов, оканчивающихся на T.
5.2.8 Тип имен переменных
Каждая переменная типа названа в одном из двух стилей:
Одна заглавная буква, за которой может следовать одна цифра (например, E
, T
, X
, T2
)
Имя в форме, используемой для классов (см. Раздел 5.2.2, Имена классов ), за которыми следует заглавная буква T (примеры: RequestT
, FooBarT
).
Вопросы
«Без этого соглашения было бы трудно определить разницу между переменной типа и обычным именем класса или интерфейса». - из руководств по Oracle, «Универсальные типы»
Односимвольные имена - не единственный способ отличить параметры типа от имен классов, как мы видели выше.
Почему бы просто не задокументировать значение параметра типа в JavaDoc?
Это правда, что @param
элементы JavaDoc могут предоставить более подробное описание. Но также верно, что JavaDocs не обязательно видны. (Например, в Eclipse есть помощник по содержимому, который показывает имена параметров типа.)
Имена параметров многосимвольных типов не соответствуют соглашению Oracle!
Многие оригинальные соглашения Sun соблюдаются почти повсеместно в программировании на Java.
Однако это конкретное соглашение не является.
Лучший выбор среди конкурирующих конвенций - это вопрос мнения. В этом случае последствия выбора соглашения, отличного от Oracle, незначительны. Вы и ваша команда можете выбрать конвенцию, которая наилучшим образом соответствует вашим потребностям.