web-dev-qa-db-fra.com

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 des enregistreurs en minuscule, ce qui constitue une violation entre PMD .

par exemple:

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

Il suffit de chercher google ou DONC pour "enregistreur final statique" et vous le verrez vous-même.

Devrions-nous utiliser LOGGER à la place?

javastaticnaming-conventionsfinallogging
227
dogbane

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 doit être en majuscule.

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

private static final double MY_CONSTANT = 0.0;
284
crunchdog

Pour ajouter plus de valeur à la réponse de crunchdog, le = Guide du style de codage Java est indiqué au paragraphe 3.3 Dénomination des champs

Les noms des champs utilisés en tant que constantes doivent être en majuscules, avec des tirets bas séparant les mots. Les éléments suivants sont considérés comme des constantes:

  1. Tout static final types primitifs (rappelez-vous que tous les champs d'interface sont, par nature, static final).
  2. Tout static final types de référence d’objet qui ne sont jamais suivis de ". "(point).
  3. Tout static final tableaux qui ne sont jamais suivis de "[ "(point).

Exemples:

MIN_VALUE, MAX_BUFFER_SIZE, OPTIONS_FILE_NAME

Suivant cette convention, logger est un static final référence d'objet comme indiqué au point 2, mais parce qu'elle est suivie de ". "chaque fois que vous l’utilisez, il ne peut pas être considéré comme une constante et doit donc être en minuscule.

216
cbliard

De Java effectif, 2e éd.,

La seule exception à la règle précédente concerne les "champs constants", dont les noms doivent comporter un ou plusieurs mots majuscules 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 modifiable, il peut rester un champ constant si l'objet référencé est immuable.

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

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

C'est immuable. D'autre part, 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 de slf4j dont le lien est ci-dessus contient un exemple dans lequel ils utilisent "enregistreur", pas "enregistreur".

Ce ne sont bien sûr que des conventions et non des règles. Si vous utilisez slf4j et que vous voulez utiliser "logger" parce que vous êtes habitué à cela depuis d'autres frameworks, ou s'il est plus facile de taper, ou pour des raisons de lisibilité, continuez.

42
Jeffrey Blattman

J'aime que Google le prenne ( 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 se sent vraiment comme une constante. Par exemple, si l'un des états observables de cette instance peut changer, ce n'est certainement pas une constante. Vouloir ne jamais muter l’objet n’est généralement pas suffisant.

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"};
33
mateuscb

Si vous utilisez un outil automatisé pour vérifier vos normes de codage et qu'il enfreint ces normes, vous devez les corriger. Si vous utilisez un standard externe, corrigez le code.

La convention dans Sun Java est une majuscule pour les constantes statiques publiques. Évidemment, un enregistreur n'est pas constant, mais représente une chose mutable (sinon, il serait inutile d'appeler des méthodes dessus dans l'espoir que quelque chose se produire), il n’existe pas de norme spécifique pour les champs finaux non constants.

10
Pete Kirkham

Si vous google cela, vous pourriez trouver que dans certains cas, les enregistreurs ne sont pas définis en tant que final statique. Ajoutez-y un peu de copier-coller, ce qui pourrait l'expliquer.

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

Nous allons même plus loin en tirant parti de la convention de nommage stricte d’Eclipse. Nous créons une nouvelle classe avec un template 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 avons besoin plus tard, nous ne faisons que commenter.

Ensuite, dans le code, nous utilisons des modèles de code qui supposent 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.

Le convention stricte nous permet d'être plus productifs et cohérents avec les modèles de code.

7
KLE

Personnellement, je pense que ça a l'air vraiment 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 à utiliser logger à la place de LOGGER. Mais si vous voulez être strictement pédant, utilisez LOGGER.

6
João Silva

N'oubliez pas que PMD respectera un commentaire avec

// NOPMD

en elle. Ainsi, PMD ignorera la ligne de ses vérifications, ce qui vous permettra de choisir le style de votre choix.

4
Fortyrunner

Généralement, les constantes sont en majuscules.

Les enregistreurs, cependant, ne doivent pas être statiques mais recherchés pour chaque "nouveau" de la classe contenante si vous utilisez la façade slf4j. Cela évite certains problèmes de chargeur de classe, notamment dans les conteneurs Web, et permet à la structure de journalisation d'effectuer des tâches spéciales en fonction du contexte d'appel.

3
Thorbjørn Ravn Andersen

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

Je ne vois aucune raison stricte pour une manière ou 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" ;-)

1
Kutzi