Un «enregistreur final statique» doit-il être déclaré en MAJUSCULE?

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 enregistreurs en minuscules, ce qui constitue une violation dans PMD .

par exemple:

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

Recherchez simplement sur Google ou SO pour "enregistreur final statique" et vous le verrez par vous-même.

Devrions-nous plutôt utiliser LOGGER?

La référence de l'enregistreur n'est pas une constante, mais une référence finale et ne doit PAS être en majuscules. Une VALEUR constante doit être en majuscules.

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

private static final double MY_CONSTANT = 0.0;

Pour ajouter plus de valeur à la réponse de crunchdog, le Java Coding Style Guide l' indique au paragraphe 3.3 Attribution d'un nom de champ

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

1. Tous static finalles types primitifs (n'oubliez pas que tous les champs d'interface sont intrinsèquement static final).
2. Tous static finalles types de référence d'objet qui ne sont jamais suivis de " ." (point).
3. Tous les static finaltableaux qui ne sont jamais suivis de " [" (ouverture du crochet carré).

Exemples:

MIN_VALUE, MAX_BUFFER_SIZE, OPTIONS_FILE_NAME

Suivant cette convention, loggerest une static finalréférence d'objet comme indiqué au point 2, mais parce qu'elle est suivie par " ." chaque fois que vous l'utilisez, elle ne peut pas être considérée comme une constante et doit donc être en minuscules.

De java efficace, 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 majuscules séparés par le caractère de soulignement, par exemple, VALEURS 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 (article 15), alors c'est 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'objet référencé est immuable.

En résumé, constante == statique finale, plus s'il s'agit d'une référence (par rapport à un type simple), l'immuabilité.

En regardant l'enregistreur slf4j, http://www.slf4j.org/api/org/slf4j/Logger.html

C'est immuable. D'un autre côté, l'enregistreur JUL est modifiable. L'enregistreur log4j est également modifiable. Donc pour être correct, si vous utilisez log4j ou JUL, ce devrait être "logger", et si vous utilisez slf4j, ce devrait être LOGGER.

Notez que la page javadocs slf4j 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" parce que vous êtes habitué à celui d'autres frameworks, ou s'il est plus facile à taper, ou pour plus de lisibilité, allez-y.

J'aime l'approche 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, demandez-vous 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. L'intention de ne jamais muter l'objet n'est généralement pas suffisante.

Exemples:

// Constants
static final int NUMBER = 5;
static final ImmutableList<String> 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<String> mutableCollection = new HashSet<String>();
static final ImmutableSet<SomeMutableType> mutableElements = ImmutableSet.of(mutable);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};

Si vous utilisez un outil automatisé pour vérifier vos normes de codage et qu'il viole lesdites normes, alors il ou les normes doivent être corrigées. 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 intérêt à appeler des méthodes dessus 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 effectuez une recherche sur Google, vous constaterez peut-être que, dans certains cas, les enregistreurs ne sont pas définis comme statiques finaux. Ajoutez un peu de copier-coller rapide à cela, et cela pourrait l'expliquer.

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

Nous allons même plus loin, en profitant de la convention de dénomination stricte 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 au départ nous n'en avons pas besoin. Mais si nous en avons besoin plus tard, nous le décommentons simplement.

Ensuite, dans le code, nous utilisons des modèles de code qui s'attendent à ce 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 stricte nous permet d'être plus productifs et cohérents avec les modèles de code .

Personnellement, je pense que ça a l'air vraiment gros en majuscules. 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 à utiliser à la loggerplace de LOGGER. Mais si vous allez être strictement pédant, utilisez-le LOGGER.

N'oubliez pas que PMD respectera un commentaire avec

// NOPMD

en elle. Cela entraînera PMD à sauter la ligne de ses vérifications, cela vous permettra de choisir le style que vous souhaitez.

Habituellement, les constantes sont en majuscules.

Les enregistreurs, cependant, ne doivent pas être statiques mais recherchent chaque "nouveau" de la classe contenante si vous utilisez la façade slf4j. Cela évite certains problèmes de chargeur de classe désagréables dans des conteneurs Web notamment, et permet au framework de journalisation de faire des choses spéciales en fonction du contexte d'appel.

Je préfère «logger», c'est-à-dire les minuscules. La raison n'est pas que c'est une constante ou pas une constante (mutable ou immuable). Si nous utilisons ce raisonnement, nous devons renommer la variable si nous modifions le cadre de journalisation (ou si le cadre modifie la mutabilité des enregistreurs).

Pour moi, d'autres raisons sont plus importantes.

1. Un enregistreur est un objet fantôme dans la classe et ne doit pas être très visible car il n'implémente pas la logique principale. Si nous utilisons 'LOGGER', c'est un accroche-regard dans le code qui attire trop d'attention.

2. Parfois, les enregistreurs sont déclarés au niveau de l'instance (c'est-à-dire qu'ils ne sont pas statiques) et sont même injectés en tant que dépendance. Je ne voudrais pas changer mon code si je décide de changer la façon dont j'obtiens l'enregistreur. La stabilité du code wrt. ce changement (hypothétique dans de nombreux cas) est l'autre raison pour laquelle je préfère les minuscules.

Si vos normes de codage - si vous en avez - disent qu'il devrait être en majuscules, alors oui.

Je ne vois aucune raison rigoureuse 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" ;-)