¿Debería declararse un “Registrador final estático” en MAYÚSCULAS?

En Java, las variables finales estáticas son constantes y la convención es que deberían estar en mayúsculas. Sin embargo, he visto que la mayoría de la gente declara los registradores en minúsculas, lo que aparece como una violación en PMD .

p.ej:

private static final Logger logger = Logger.getLogger(MyClass.class); 

Simplemente busque en google o SO para “registrador final estático” y verá esto usted mismo.

¿Deberíamos usar LOGGER en su lugar?

La referencia del registrador no es una constante, sino una referencia final, y NO debe estar en mayúsculas. Un VALOR constante debe estar en mayúscula.

 private static final Logger logger = Logger.getLogger(MyClass.class); private static final double MY_CONSTANT = 0.0; 

Para agregar más valor a la respuesta de crunchdog, la Guía de estilo de encoding de Java lo indica en el párrafo 3.3 Nomenclatura de campo

Los nombres de los campos que se usan como constantes deben ser mayúsculas, con caracteres de subrayado que separen las palabras. Los siguientes se consideran constantes:

  1. Todos los tipos primitivos static final (recuerde que todos los campos de la interfaz son inherentemente static final ).
  2. Todos static final tipos de referencia de objeto static final que nunca son seguidos por ” . ” (Punto).
  3. Todas las matrices static final que nunca son seguidas por ” [ ” (punto).

Ejemplos:

 MIN_VALUE, MAX_BUFFER_SIZE, OPTIONS_FILE_NAME 

Siguiendo esta convención, el logger es una referencia de objeto static final como se indica en el punto 2, pero debido a que está seguido de ” . ” Cada vez que lo usa, no puede considerarse como una constante y, por lo tanto, debe estar en minúscula.

De Java efectiva, 2nd ed.,

La única excepción a la regla anterior se refiere a “campos constantes”, cuyos nombres deben consistir en una o más palabras en mayúsculas separadas por el carácter de subrayado, por ejemplo, VALORES o NEGATIVO_INFINIDAD. Un campo constante es un campo final estático cuyo valor es inmutable . Si un campo final estático tiene un tipo primitivo o un tipo de referencia inmutable (Elemento 15), entonces es un campo constante. Por ejemplo, las constantes enum son campos constantes. Si un campo final estático tiene un tipo de referencia mutable, aún puede ser un campo constante si el objeto al que se hace referencia es inmutable.

En resumen, constant == static final, más si se trata de una referencia (frente a un tipo simple), inmutabilidad.

En cuanto al registrador slf4j, http://www.slf4j.org/api/org/slf4j/Logger.html

Es inmutable Por otro lado, el registrador JUL es mutable. El registrador log4j también es mutable. Entonces, para ser correcto, si está usando log4j o JUL, debería ser “logger”, y si está usando slf4j, debería ser LOGGER.

Tenga en cuenta que la página slf4j javadocs vinculada arriba tiene un ejemplo donde usan “logger”, no “LOGGER”.

Estas son, por supuesto, solo convenciones y no reglas. Si está usando slf4j y quiere usar “logger” porque está acostumbrado a eso de otros frameworks, o si es más fácil de escribir, o de legibilidad, siga adelante.

Me gusta el enfoque de Google ( estilo Google Java )

Cada constante es un campo final estático, pero no todos los campos finales estáticos son constantes. Antes de elegir el caso constante, considere si el campo realmente se siente como una constante. Por ejemplo, si cualquiera de los estados observables de esa instancia puede cambiar, es casi seguro que no es una constante. Simplemente, intentar nunca mutar el objeto generalmente no es suficiente.

Ejemplos:

 // Constants static final int NUMBER = 5; static final ImmutableList NAMES = ImmutableList.of("Ed", "Ann"); static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is immutable static final SomeMutableType[] EMPTY_ARRAY = {}; enum SomeEnum { ENUM_CONSTANT } // Not constants static String nonFinal = "non-final"; final String nonStatic = "non-static"; static final Set mutableCollection = new HashSet(); static final ImmutableSet mutableElements = ImmutableSet.of(mutable); static final Logger logger = Logger.getLogger(MyClass.getName()); static final String[] nonEmptyArray = {"these", "can", "change"}; 

Si está utilizando una herramienta automatizada para verificar sus estándares de encoding y viola dichos estándares, entonces o los estándares deben ser reparados. Si está utilizando un estándar externo, arregle el código.

La convención en Sun Java es mayúscula para las constantes estáticas públicas. Obviamente, un registrador no es constante, pero representa una cosa mutable (de lo contrario no habría ningún método de invocación de puntos en él con la esperanza de que algo suceda); no hay un estándar específico para campos finales no constantes.

Si googleas esto, es posible que encuentres que, en algunos casos, los registradores no están definidos como estáticos finales. Agregue un poco de copiar y pegar rápido a esto, y esto podría explicarlo.

Usamos LOGGER en todo nuestro código, y esto corresponde a nuestra convención de nomenclatura (y nuestro CheckStyle está contento con él).


Incluso vamos más allá, aprovechando la estricta convención de nombres en Eclipse. Creamos una nueva clase con una plantilla de código de:

  // private static final Logger LOGGER = Logger.getLogger(${enclosing_type}.class); 

El registrador está comentado, ya que inicialmente no lo necesitamos. Pero si lo necesitamos más tarde, simplemente lo descomentamos.

Luego, en el código, usamos plantillas de código que esperan que este registrador esté presente. Ejemplo con la plantilla try-catch:

  try { ${cursor} or some other template } catch (Exception t) { LOGGER.error("${methodName} ${method parameters}", t); } 

Tenemos algunas plantillas más que lo usan.

La estricta convención nos permite ser más productivos y coherentes con las plantillas de código .

Personalmente creo que se ve muy grande en mayúsculas. Además, dado que es una clase que no está directamente relacionada con el comportamiento de clase, no veo un problema importante al usar el logger lugar de LOGGER . Pero si vas a ser estrictamente pedante, entonces usa LOGGER .

No olvides que PMD respetará un comentario con

 // NOPMD 

en eso. Esto hará que PMD omita la línea de sus cheques, esto le permitirá elegir el estilo que desee.

Usualmente las constantes están en mayúsculas.

Los madereros, sin embargo, no deberían ser estáticos sino que buscaron cada “nuevo” de la clase contenedora si usaban la fachada slf4j. Esto evita algunos problemas desagradables del cargador de clases en contenedores notablemente web, además permite que el marco del registrador haga cosas especiales dependiendo del contexto de invocación.

Si sus estándares de encoding, si los tiene, diga que deberían estar en mayúsculas, entonces sí.

No veo ninguna razón estricta para una forma u otra. Creo que depende totalmente de tus gustos personales resp. los estándares de encoding de su empresa.

Por cierto: prefiero “LOGGER” 😉