Un «enregistreur final statique» doit-il être déclaré dans UPPER-CASE?

En Java, les variables finales statiques sont des constantes et la convention est qu’elles doivent être en majuscules. Cependant, j’ai vu que la plupart des gens déclarent les bûcherons en minuscule, ce qui apparaît comme une violation dans PMD .

par exemple:

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

Il suffit de rechercher Google ou SO pour “logger final statique” et vous le verrez par vous-même.

Devrions-nous utiliser LOGGER à la place?

La référence de l’enregistreur n’est pas une constante, mais une référence finale, et ne doit PAS être en majuscule. Une valeur constante devrait être en majuscule.

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

Pour append plus de valeur à la réponse de crunchdog, le Guide de style de codage Java indique ceci dans le paragraphe 3.3 Atsortingbution de nom de champ

Les noms de champs utilisés en tant que constantes doivent être en majuscules, avec des traits de soulignement qui séparent les mots. Les éléments suivants sont considérés comme des constantes:

  1. Tous les types primitifs static final (N’oubliez pas que tous les champs d’interface sont insortingnsèquement static final ).
  2. Tous static final types de référence d’object static final qui ne sont jamais suivis de ” . ” (Point).
  3. Tous static final tableaux static final qui ne sont jamais suivis de ” [ ” (point).

Exemples:

 MIN_VALUE, MAX_BUFFER_SIZE, OPTIONS_FILE_NAME 

Suite à cette convention, logger est une référence d’object static final comme indiqué au point 2, mais parce qu’il est suivi de ” . ” Chaque fois que vous l’utilisez, il ne peut pas être considéré comme une constante et doit donc être en minuscule.

De Java effectif, 2e éd.,

La seule exception à la règle précédente concerne les «champs constants», dont les noms doivent consister en un ou plusieurs mots en majuscule séparés par le caractère de soulignement, par exemple, VALUES ou NEGATIVE_INFINITY. Un champ constant est un champ final statique dont la valeur est immuable . Si un champ final statique a un type primitif ou un type de référence immuable (élément 15), il s’agit d’un champ constant. Par exemple, les constantes enum sont des champs constants. Si un champ final statique a un type de référence mutable, il peut toujours être un champ constant si l’object référencé est immuable.

En résumé, constante == finale statique, plus si c’est une référence (vs. un type simple), l’immuabilité.

En regardant le logger de slf4j, http://www.slf4j.org/api/org/slf4j/Logger.html

C’est immuable. Par contre, le logger JUL est mutable. Le log4j logger est également mutable. Donc, pour être correct, si vous utilisez log4j ou JUL, cela devrait être “logger”, et si vous utilisez slf4j, cela devrait être LOGGER.

Notez que la page slav4j javadocs liée ci-dessus a un exemple où ils utilisent “logger”, pas “LOGGER”.

Ce ne sont bien sûr que des conventions et non des règles. Si vous utilisez slf4j et que vous souhaitez utiliser “logger” car vous êtes habitué à cela par d’autres frameworks, ou si c’est plus facile à taper, ou à des fins de lisibilité, allez-y.

J’aime la prise de Google ( Google Java Style )

Chaque constante est un champ final statique, mais tous les champs finaux statiques ne sont pas des constantes. Avant de choisir un cas constant, déterminez si le champ ressemble vraiment à une constante. Par exemple, si l’un des états observables de cette instance peut changer, ce n’est certainement pas une constante. Le simple fait de ne jamais muter l’object n’est généralement pas suffisant.

Exemples:

 // 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 Ssortingng nonFinal = "non-final"; final Ssortingng 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 Ssortingng[] nonEmptyArray = {"these", "can", "change"}; 

Si vous utilisez un outil automatisé pour vérifier vos normes de codage et que celles-ci ne respectent pas ces normes, il convient de les corriger ou de les corriger. Si vous utilisez un standard externe, corrigez le code.

La convention dans Sun Java est en majuscule pour les constantes statiques publiques. De toute évidence, un enregistreur n’est pas constant, mais représente une chose mutable (sinon, il n’y aurait aucun moyen d’appeler des méthodes dans l’espoir que quelque chose se produise); Il n’y a pas de norme spécifique pour les champs finaux non constants.

Si vous utilisez Google, vous constaterez que dans certains cas, les enregistreurs ne sont pas définis comme étant statiques. Ajoutez un peu de copier-coller rapide à ceci, et cela pourrait l’expliquer.

Nous utilisons LOGGER dans tout notre code, et cela correspond à notre convention de dénomination (et notre CheckStyle en est satisfait).


Nous allons même plus loin, profitant de la convention de dénomination ssortingcte d’Eclipse. Nous créons une nouvelle classe avec un modèle de code de:

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

L’enregistreur est commenté, car initialement nous n’en avons pas besoin. Mais si nous en avions besoin plus tard, nous le décommentons tout simplement.

Ensuite, dans le code, nous utilisons des modèles de code qui attendent que cet enregistreur soit présent. Exemple avec le modèle try-catch:

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

Nous avons quelques autres modèles qui l’utilisent.

La convention ssortingcte nous permet d’être plus productif et cohérent avec les modèles de code .

Personnellement, je pense que ça a l’air très gros en majuscule. De plus, comme c’est une classe qui n’est pas directement liée au comportement de la classe, je ne vois pas de problème majeur dans l’utilisation de logger place de LOGGER . Mais si vous voulez être ssortingctement pédant, utilisez alors LOGGER .

N’oubliez pas que PMD respectera un commentaire avec

 // NOPMD 

dedans. Cela entraînera PMD à sauter la ligne de ses contrôles, cela vous permettra de choisir le style que vous voulez.

Les constantes sont généralement en majuscules.

Les enregistreurs, cependant, ne devraient pas être statiques mais recherchaient chaque “nouveau” de la classe contenant la façade slf4j. Cela évite certains problèmes de classloader désagréables, notamment les conteneurs Web, et permet au framework de journalisation de faire des choses spéciales en fonction du contexte d’appel.

Si vos normes de codage – si vous en avez – disent que cela devrait être majuscule alors oui.

Je ne vois aucune raison ssortingcte d’une manière ou d’une autre. Je pense que cela dépend totalement de vos goûts personnels resp. les normes de codage de votre entreprise.

BTW: je préfère “LOGGER” 😉