java - practicas - nombrado de variables métodos y constantes

¿Rompiendo la convención de nombres de genéricos de java? (7)

Me pregunto si puedo (debería) romper la convención de nombres de Java para hacer esto:

No, esto debe evitarse ya que es más fácil confundir los parámetros de tipo con constantes y otros identificadores.

Aquí hay una cita del rastro oficial sobre genéricos :

Convenciones de nomenclatura de parámetros de tipo
Por convención, los nombres de los parámetros de tipo son letras mayúsculas y únicas . Esto contrasta claramente con las convenciones de nombres de variables que ya conoce, y con buena razón: sin esta convención, sería difícil distinguir la diferencia entre una variable de tipo y un nombre de interfaz o clase común .
Los nombres de parámetros de tipo más utilizados son:
E - Elemento (usado extensivamente por el Java Collections Framework)
K - Clave
N - Número
Tipo T
V - Valor
S , U , V etc. - 2do, 3ro, 4to tipos
Verá estos nombres utilizados en la API de Java SE y el resto de este tutorial.

Esta pregunta ya tiene una respuesta aquí:

¿Tipo genérico de convención de nomenclatura de parámetros para Java (con múltiples caracteres)? 5 respuestas

Tengo una interfaz cuya declaración es la siguiente:

/** * @param T - the type of entity. * @param C - the type of entity container will be returned. */ public interface FindByNamedQuery<T extends Serializable, C extends Collection<T>> extends Command { C executeNamedQuery(String namedQuery); }

Me pregunto si puedo (debería) romper la convención de nomenclatura de Java para hacer esto:

public interface FindByNamedQuery<ENTITY_TYPE extends Serializable, RETURNED_CONTAINER extends Collection<ENTITY_TYPE>> extends Command { RETURNED_CONTAINER executeNamedQuery(String namedQuery); }

Al igual que Allen antes , mi consejo viene más de C # (que uso extensivamente desde hace 5 meses) que de Java (con el que jugué, pero nunca fue muy lejos ...), pero me parece que Java y el código C # son muy similares en espíritu ( es decir, cuando se compara con, digamos, C ++)

De todos modos, cuando utilizo un C # / Java genérico (o una plantilla de C ++) en un tipo simple, generalmente uso T:

// C++ template<typename T> class MyClass { /* ... */ } ; // C# public MyClass<T> { /* etc. */ } // Java public MyClass<T> { /* etc. */ }

Generalmente, el tipo T va con la clase, por lo que no hay necesidad de describirlo más.

Pero cuando realmente describo el tipo se agrega a la claridad del código, lo hago.

O cuando tengo dos o más tipos en la misma declaración genérica / plantilla, ayuda a hacer la diferencia entre dos tipos. Por ejemplo (ejemplo de la vida real en C #):

// C++ template<typename T_Data, typename T_Underlying> class MyClass { /* ... */ } ; // C# public MyClass<T_Data, T_Underlying> { /* etc. */ } // Java public MyClass<T_Data, T_Underlying> { /* etc. */ }

De esta manera, es fácil hacer la diferencia entre los dos nombres de tipo en el código, donde T y U son, bueno ... un poco anónimo: Para aquellos que usan Visual C ++, van a depurar el código STL de Dinkumware, lleno de T , _U y otros nombres tipográficos de una sola letra pueden ser bastante frustrantes ... Supongo que lo mismo ocurre con el código C # o Java.

Notarás que en cada caso (C ++, Java o C #), no sigo la convención en alguna parte en mis nombres de tipo: la razón es que a veces, solo tienes que intentar algo más en lugar de seguir la manada, incluso si Al final, encontrarás que estás equivocado.

En el caso actual, la violación de la convención de nomenclatura no es crítica (hay peores problemas en Java que este pequeño crimen), y al final, aprenderá personalmente y exactamente POR QUÉ está mal, en lugar de citar documentos antiguos.

Y si encuentras al final tienes razón, bueno ...

Creo que esta es la queja de muchas personas que usan genéricos. No estoy del todo de acuerdo con la afirmación de Sun de que si usa un nombre completo, entonces se confundirá con un nombre de clase existente o algo más. En ese caso, podemos comenzar el nombre del marcador de posición con un dólar como este:

public class HashMap<$Key,$Value> implements Map<$Key,$Value>{}

Nadie en su sano juicio nombra una clase que comienza con un signo de dólar. Y un signo de dólar también se usa para indicar un marcador de posición, la velocidad de muchos lenguajes, los puntales, la primavera, etc. Creo que este es el camino a seguir.

Tengo más detalles sobre esto y el razonamiento detrás de no tener que usar una notación de una sola letra en mi publicación del blog si alguien está interesado.

http://readsethu.wordpress.com/2012/05/23/a-generic-class-and-why-is-it-confusing/

Es posible que el compilador no se queje, pero es posible que sus compañeros de equipo no aprecien que use lo que parece ser una constante en un lugar donde esperan un parámetro de tipo.

Estoy empezando a estar en desacuerdo con la convención de un solo personaje, después de usarla desde mediados de los años noventa.

Encuentro los nombres legibles más legibles. Esto es útil para comprender tanto la implementación como la interfaz de los tipos genéricos.

El problema de la ambigüedad parece exagerado para Java. Pocos nombres de clase están en mayúsculas. Las constantes no se usan en el mismo contexto que los nombres de clase.

Es cierto que los elementos de JavaDoc @param pueden proporcionar una descripción más larga. Pero también es cierto que los JavaDocs no son necesariamente visibles. (Por ejemplo, hay una ayuda de contenido en Eclipse que muestra los nombres de los parámetros de tipo).

Por ejemplo, compara:

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

Aunque los nombres de un solo carácter han sido recomendados como una convención por Sun / Oracle, se pueden cambiar las convenciones. Las consecuencias de desafiar esta convención son menores. Si usted y su equipo prefieren nombres significativos para sus parámetros de tipo, yo personalmente lo haría.

Editar (2015)

Google style para Java permite que tanto los nombres de una sola letra como los de tipo de clase de varios caracteres que terminen en T.

5.2.8 Escriba los nombres de las 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 el formulario utilizado para las clases (consulte la Sección 5.2.2, Nombres de las clases), seguido de la letra mayúscula T (ejemplos: RequestT, FooBarT).

Usar TDescription es bastante común en C #. Mantiene el nombre T, pero también es descriptivo al mismo tiempo, así:

public interface FindByNamedQuery< TEntityType extends Serialiazble, TReturnedContainer extends Collections<TEntityType>> extends Command { TReturnedContainer executeNamedQuery(String namedQuery); }

Como han dicho otros, ALL_CAPS casi siempre indica una constante.

En mi opinión, "sería difícil distinguir la diferencia entre una variable de tipo y un nombre de clase o interfaz ordinarios". no se aplica aquí, porque el prefijo T lo identifica fácilmente como una variable de tipo.

Nuevamente, esto es C # pero vea MSDN: Convenciones de nomenclatura para genéricos

En todos los demás casos, las pautas oficiales de Microsoft para las convenciones de nombres genéricos son:
Nombre los parámetros de tipo genérico con nombres descriptivos, a menos que un solo nombre de letra se explique por sí mismo y un nombre descriptivo no agregue valor.
public interface ISessionChannel<TSession> {...} public delegate TOutput Converter<TInput,TOutput>(TInput from);
Considere indicar las restricciones colocadas en un parámetro de tipo en el nombre del parámetro. Por ejemplo, un parámetro restringido a ISession puede llamarse TSession.

Yo nombraría variables de tipo similares a los tipos, en tripa de camello, pero con el prefijo "_".

public interface FindByNamedQuery <_EntityType extends Serialiazble, _ReturnedContainer extends Collections<_EntityType>> extends Command { _ReturnedContainer executeNamedQuery(String namedQuery); }