Sollte in UPPER-CASE ein "statischer Endlogger" deklariert werden?

In Java sind statische Endvariablen Konstanten, und die Konvention lautet, dass sie in Großbuchstaben geschrieben werden sollten. Ich habe jedoch gesehen, dass die meisten Leute Logger in Kleinbuchstaben deklarieren, was einen Verstoß gegen PMD darstellt .

z.B:

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

Suchen Sie einfach in Google oder SO nach "static final logger" und Sie werden es selbst sehen.

Sollten wir stattdessen LOGGER verwenden?

Die Logger-Referenz ist keine Konstante, sondern eine endgültige Referenz und sollte NICHT in Großbuchstaben geschrieben werden. Ein konstanter WERT sollte in Großbuchstaben angegeben werden.

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

private static final double MY_CONSTANT = 0.0;

Um der Antwort von crunchdog mehr Wert zu verleihen, wird dies im Java Coding Style Guide in Abschnitt 3.3 Feldbenennung angegeben

Die Namen der Felder, die als Konstanten verwendet werden, sollten alle in Großbuchstaben geschrieben sein, wobei die Unterstriche die Wörter trennen. Folgendes wird als Konstante betrachtet:

1. Alle static finalprimitiven Typen (Denken Sie daran, dass alle Schnittstellenfelder von Natur aus sind static final).
2. Alle static finalObjektreferenztypen, denen niemals " ." (Punkt) folgt .
3. Alle static finalArrays, denen niemals " [" folgt (öffnende eckige Klammer).

Beispiele:

MIN_VALUE, MAX_BUFFER_SIZE, OPTIONS_FILE_NAME

Im Anschluss an diese Konvention loggerist ein static finalObjektverweis als Nummer 2 angegeben ist , sondern weil es ist von „gefolgt .“ jedes Mal wenn Sie es verwenden, kann es nicht als konstant betrachtet werden und somit sollte niedriger Fall sein.

Aus effektivem Java, 2. Aufl.,

Die einzige Ausnahme von der vorherigen Regel betrifft "konstante Felder", deren Namen aus einem oder mehreren Großbuchstaben bestehen sollten, die durch den Unterstrich getrennt sind, z. B. VALUES oder NEGATIVE_INFINITY. Ein konstantes Feld ist ein statisches Endfeld, dessen Wert unveränderlich ist . Wenn ein statisches Endfeld einen primitiven Typ oder einen unveränderlichen Referenztyp hat (Punkt 15), ist es ein konstantes Feld. Enum-Konstanten sind beispielsweise konstante Felder. Wenn ein statisches Endfeld einen veränderlichen Referenztyp hat, kann es immer noch ein konstantes Feld sein, wenn das referenzierte Objekt unveränderlich ist.

Zusammenfassend ist Konstante == statisches Finale plus, wenn es sich um eine Referenz (im Vergleich zu einem einfachen Typ) handelt, Unveränderlichkeit.

Schauen Sie sich den slf4j-Logger an: http://www.slf4j.org/api/org/slf4j/Logger.html

Es ist unveränderlich. Andererseits ist der JUL-Logger veränderbar. Der log4j-Logger ist ebenfalls veränderbar. Um korrekt zu sein, wenn Sie log4j oder JUL verwenden, sollte es "logger" sein, und wenn Sie slf4j verwenden, sollte es LOGGER sein.

Beachten Sie, dass die oben verlinkte javadocs-Seite slf4j ein Beispiel enthält, in dem "logger" und nicht "LOGGER" verwendet wird.

Dies sind natürlich nur Konventionen und keine Regeln. Wenn Sie zufällig slf4j verwenden und "logger" verwenden möchten, weil Sie dies von anderen Frameworks gewohnt sind, oder wenn es einfacher zu tippen oder lesbar ist, fahren Sie fort.

Ich mag Googles Einstellung ( Google Java Style )

Jede Konstante ist ein statisches Endfeld, aber nicht alle statischen Endfelder sind Konstanten. Überlegen Sie sich vor der Auswahl eines konstanten Falls, ob sich das Feld wirklich wie eine Konstante anfühlt. Wenn sich beispielsweise einer der beobachtbaren Zustände dieser Instanz ändern kann, ist dies mit ziemlicher Sicherheit keine Konstante. Die bloße Absicht, das Objekt niemals zu mutieren, reicht im Allgemeinen nicht aus.

Beispiele:

// 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"};

Wenn Sie ein automatisiertes Tool verwenden, um Ihre Codierungsstandards zu überprüfen, und diese gegen diese Standards verstoßen, sollten diese oder die Standards behoben werden. Wenn Sie einen externen Standard verwenden, korrigieren Sie den Code.

Die Konvention in Sun Java ist Großbuchstaben für öffentliche statische Konstanten. Offensichtlich ist ein Logger nicht konstant, sondern stellt eine veränderbare Sache dar (andernfalls wäre es sinnlos, Methoden darauf aufzurufen, in der Hoffnung, dass etwas passieren wird); Es gibt keinen spezifischen Standard für nicht konstante Endfelder.

Wenn Sie dies googeln, stellen Sie möglicherweise fest, dass die Logger in einigen Fällen nicht als statisches Finale definiert sind. Fügen Sie etwas schnelles Kopieren und Einfügen hinzu, und dies könnte es erklären.

Wir verwenden LOGGER in unserem gesamten Code, und dies entspricht unserer Namenskonvention (und unser CheckStyle ist damit zufrieden).

Wir gehen sogar noch weiter und nutzen die strenge Namenskonvention in Eclipse. Wir erstellen eine neue Klasse mit einer Codevorlage von:

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

Der Logger ist auskommentiert, da wir ihn zunächst nicht brauchen. Aber sollten wir es später brauchen, kommentieren wir es einfach aus.

Dann verwenden wir im Code Codevorlagen, die erwarten, dass dieser Logger vorhanden ist. Beispiel mit der Try-Catch-Vorlage:

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

Wir haben noch ein paar Vorlagen, die es verwenden.

Die strenge Konvention ermöglicht es uns, produktiver und kohärenter mit Codevorlagen umzugehen .

Ich persönlich denke, dass es in Großbuchstaben wirklich groß aussieht. Da es sich um eine Klasse handelt, die nicht direkt mit dem Klassenverhalten zusammenhängt, sehe ich kein großes Problem darin, loggerstattdessen zu verwenden LOGGER. Aber wenn Sie streng pedantisch sein wollen, dann verwenden Sie LOGGER.

Vergessen Sie nicht, dass PMD einen Kommentar mit respektiert

// NOPMD

drin. Dies führt dazu, dass PMD die Zeile von seinen Überprüfungen überspringt. Auf diese Weise können Sie den gewünschten Stil auswählen.

Normalerweise werden Konstanten in Großbuchstaben geschrieben.

Logger sollten jedoch nicht statisch sein, sondern bei Verwendung der slf4j-Fassade nach jedem "neuen" der enthaltenen Klasse suchen. Dies vermeidet einige unangenehme Classloader-Probleme in insbesondere Webcontainern und ermöglicht es dem Logger-Framework, abhängig vom Aufrufkontext spezielle Aufgaben auszuführen.

Ich bevorzuge 'Logger', dh Kleinbuchstaben. Der Grund ist nicht, dass es eine Konstante oder keine Konstante ist (veränderlich oder unveränderlich). Wenn wir diese Argumentation verwenden würden, müssten wir die Variable umbenennen, wenn wir das Protokollierungsframework ändern (oder wenn das Framework die Veränderbarkeit von Protokollierern ändert).

Für mich sind andere Gründe wichtiger.

1. Ein Logger ist ein Schattenobjekt in der Klasse und sollte nicht sehr prominent sein, da er die Hauptlogik nicht implementiert. Wenn wir 'LOGGER' verwenden, ist dies ein Blickfang im Code, der zu viel Aufmerksamkeit erregt.

2. Manchmal werden Logger auf Instanzebene deklariert (dh nicht als statisch) und sogar als Abhängigkeit eingefügt. Ich möchte meinen Code nicht ändern, wenn ich die Art und Weise, wie ich den Logger erhalte, ändern möchte. Die Codestabilität wrt. Diese (in vielen Fällen hypothetische) Änderung ist der andere Grund, warum ich Kleinbuchstaben bevorzuge.

Wenn Ihre Codierungsstandards - falls vorhanden - sagen, dass sie in Großbuchstaben geschrieben werden sollten, dann ja.

Ich sehe keinen strengen Grund für die eine oder andere Weise. Ich denke, es hängt ganz von Ihren persönlichen Vorlieben ab. die Kodierungsstandards Ihres Unternehmens.

Übrigens: Ich bevorzuge "LOGGER" ;-)