programación - ¿Convención de nomenclatura de parámetros genéricos para Java(con múltiples caracteres)?
nomenclatura del lenguaje de programación java (5)
Agregar Type
Se puede encontrar una buena discusión en los comentarios en la página de DZone, Convenciones de nombres para tipos parametrizados .
Vea el comentario de Erwin Mueller. Su sugerencia tiene perfecto sentido obvio para mí: añada la palabra Type .
Llama a una manzana una manzana, un auto a un auto. El nombre en cuestión es el nombre de un tipo de datos, ¿verdad? (En OOP , una clase esencialmente define un nuevo tipo de datos.) Así que llámalo "Tipo".
El ejemplo de Mueller, extraído del artículo original de la publicación:
public interface ResourceAccessor <ResourceType, ArgumentType, ResultType> {
public ResultType run (ResourceType resource, ArgumentType argument);
}
Anexar T
Una pregunta duplicada proporciona esta Respuesta de Andy Thomas. Tenga en cuenta el extracto de la guía de estilo de Google que sugiere que un nombre de tipo de múltiples caracteres debe terminar en una sola T mayúscula.
En algunas interfaces que escribí me gustaría nombrar parámetros de tipo genérico con más de un carácter para hacer que el código sea más legible.
Algo como....
Map<Key,Value>
En lugar de esto...
Map<K,V>
Pero cuando se trata de métodos, los parámetros de tipo parecen clases Java, lo que también es confuso.
public void put(Key key, Value value)
Parece que Key y Value son clases. Encontré o pensé en algunas anotaciones, pero nada como una convención de Sun o una mejor práctica general.
Alternativas que adiviné o encontré ...
Map<KEY,VALUE>
Map<TKey,TValue>
La razón por la cual la convención de nomenclatura oficial recomienda usar una sola letra es la siguiente:
Sin esta convención, sería difícil determinar la diferencia entre una variable de tipo y una clase ordinaria o nombre de interfaz.
Creo que con IDE modernos esa razón ya no es válida como, por ejemplo. IntelliJ Idea muestra parámetros de tipo genérico con diferentes colores que las clases regulares.
Código con tipo genérico como se muestra en IntelliJ Idea 2016.1
Debido a esa distinción , uso nombres descriptivos más largos para mis tipos genéricos, con la misma convención que los tipos regulares. Evito agregar prefijos y sufijos como T o Type porque los considero ruido innecesario y ya no es necesario distinguir visualmente los tipos genéricos.
Nota: Como no soy usuario de Eclipse o Netbeans, no sé si ofrecen una función similar.
Oracle recomienda lo siguiente en Java Tutorials> Generics> Generic Types :
Tipo convenciones de nomenclatura de parámetros
Por convención, los nombres de los parámetros de tipo son letras simples y mayúsculas. Esto contrasta fuertemente con las convenciones de naming variable que ya conoce, y con una buena razón: sin esta convención, sería difícil distinguir entre una variable de tipo y una clase ordinaria o nombre de interfaz.
Los nombres de parámetros de tipo más utilizados son:
- E - Element (usado ampliamente por el Java Collections Framework)
- K - Clave
- N - Número
- T - Tipo
- V - Valor
- S, U, V etc. - 2 °, 3 °, 4 ° tipos
Verá estos nombres usados a lo largo de la API de Java SE y el resto de esta lección.
Me aferraría a esto para evitar la confusión entre los desarrolladores y posibles mantenedores.
Puede usar javadoc para dar una clave a los usuarios de su clase genérica. Todavía no me gusta (estoy de acuerdo con @ chaper29) pero los documentos me ayudan.
p.ej,
/**
*
* @param <R> - row
* @param <C> - column
* @param <E> - cell element
*/
public class GenericTable<R, C, E> {
}
La otra cosa que se sabe que hago es usar mi IDE para refactorizar una clase que rompe la convención. Luego, trabaje en el código y refactorice de vuelta a letras simples. Me lo hace más fácil de todos modos si se usan muchos parámetros de tipo.
Sí, puede usar nombres de múltiples caracteres para variables de tipo, siempre que se distingan claramente de los nombres de clase.
Esto difiere de la convención sugerida por Sun con la introducción de los genéricos en 2004. Sin embargo:
- Existe más de una convención.
- Los nombres de varios caracteres son consistentes con otros estilos de Java, como el estilo de Google para Java .
- Los nombres legibles son (¡sorpresa!) Más legibles.
Legibilidad
En algunas interfaces que escribí me gustaría nombrar un parámetro de tipo genérico con más de un carácter para hacer que el código sea más legible.
La legibilidad es buena.
Comparar:
public final class EventProducer<L extends IEventListener<E>,E>
implements IEventProducer<L,E> {
a:
public final class EventProducer<LISTENER extends IEventListener<EVENT>,EVENT>
implements IEventProducer<LISTENER, EVENT> {
o, con la convención multi-personaje de 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> {
Estilo de Google
La Guía de estilo de Google Java permite tanto nombres de una sola letra como nombres de clases de varios caracteres que terminan en T.
5.2.8 Escriba nombres de variables
Cada variable de tipo se nombra en uno de dos estilos:
Una sola letra mayúscula, opcionalmente seguida de un solo número (como
E,T,X,T2)Un nombre en la forma utilizada para las clases (consulte la Sección 5.2.2, Nombres de clase ), seguido de la letra mayúscula T (ejemplos:
RequestT,FooBarT).
Cuestiones
"Sin esta convención, sería difícil distinguir entre una variable de tipo y una clase común o nombre de interfaz." - de los tutoriales de Oracle, "Tipos genéricos"
Los nombres de un solo carácter no son la única forma de distinguir los parámetros de tipo de los nombres de clase, como hemos visto anteriormente.
¿Por qué no solo documentar el significado del parámetro de tipo en JavaDoc?
Es cierto que los elementos @param JavaDoc pueden proporcionar una descripción más larga. Pero también es cierto que los JavaDocs no son necesariamente visibles. (Por ejemplo, hay una asistencia de contenido en Eclipse que muestra los nombres de los parámetros de tipo).
Los nombres de los parámetros de tipo de caracteres múltiples no siguen la convención de Oracle.
Muchas de las convenciones originales de Sun se siguen casi universalmente en la programación de Java.
Sin embargo, esta convención en particular no lo es.
La mejor opción entre las convenciones competidoras es una cuestión de opinión. Las consecuencias de elegir una convención diferente a la de Oracle en este caso son menores. Usted y su equipo pueden elegir una convención que mejor se adapte a sus necesidades.