it-swarm.com.de

Namenskonvention: Endgültige Felder (nicht statisch)

Heute hatte ich eine Diskussion mit einem Kollegen über die Benennung von final Feldern in Java Klassen.

In seiner Stellungnahme sollten final Felder ebenfalls als Konstanten betrachtet werden, da sich ihre Werte nach dem Erstellen der Instanz nicht ändern.

Dies würde zu der folgenden Namenskonvention für final Felder führen:

public class Foo {
    private static final String BLA_BLA = "bla";

    private final String BAR_BATZ;

    ...
}

Meiner Meinung nach nur static final Felder sollten als Konstanten betrachtet werden, während Felder, die nur final sind, der üblichen camelCase-Namenskonvention folgen sollten.

public class Foo {
    private static final String BLA = "bla";

    private final String barBatz;

    ...
}

Jetzt bin ich etwas unsicher, da er ein weitaus erfahrenerer Programmierer ist als ich und ich normalerweise seiner Meinung zustimme und ihn als einen sehr guten Entwickler betrachte.

Irgendwelche Eingaben dazu?

25
Sascha Wolf

Sun (und jetzt Oracle) unterhielt ein Dokument mit dem Titel Code Conventions for the Java Programming Language . Das letzte Update dazu war '99, aber die Essenz des Stils Richtlinie lebt weiter.

Kapitel 9 behandelt Namenskonventionen.

Für einen Bezeichner-Typ von 'Konstanten':

Die Namen der als Klassenkonstanten deklarierten Variablen und der ANSI-Konstanten sollten alle in Großbuchstaben mit durch Unterstriche ("_") getrennten Wörtern angegeben werden. (ANSI-Konstanten sollten zur Erleichterung des Debuggens vermieden werden.)

Die angegebenen Beispiele:

static final int MIN_WIDTH = 4;

static final int MAX_WIDTH = 999;

static final int GET_THE_CPU = 1;

In einem neueren Dokument - es ist dort reingeschlichen. Von Variablen (Die Java Tutorials> Lernen der Java Sprache> Sprachgrundlagen :

Wenn der von Ihnen gewählte Name nur aus einem Wort besteht, buchstabieren Sie dieses Wort in Kleinbuchstaben. Wenn es aus mehr als einem Wort besteht, schreiben Sie den ersten Buchstaben jedes nachfolgenden Wortes in Großbuchstaben. Die Namen gearRatio und currentGear sind Paradebeispiele für diese Konvention. Wenn Ihre Variable einen konstanten Wert wie static final int NUM_GEARS = 6 Speichert, ändert sich die Konvention geringfügig, wobei jeder Buchstabe groß geschrieben und nachfolgende Wörter durch den Unterstrich getrennt werden. Konventionell wird der Unterstrich an keiner anderen Stelle verwendet.

Viele statische Analysatoren für Java versuchen dies zu erzwingen. Zum Beispiel checkstyle erzwingt:

Überprüft, ob Konstantennamen einem durch die format-Eigenschaft angegebenen Format entsprechen. Eine Konstante ist ein statisches und endgültiges Feld oder ein Schnittstellen-/Anmerkungsfeld mit Ausnahme von serialVersionUID und serialPersistentFields. Das Format ist ein regulärer Ausdruck und standardmäßig ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$.


Dies läuft wirklich auf die Konventionen der Community hinaus, die den Code schreibt ... und ihn im Idealfall gleich hält.

Die obigen Beispiele werden als static final Angegeben, die wahrscheinlich von den C-Konventionen für #define Abgeleitet sind - die wie C im Code während der Kompilierung und nicht zur Laufzeit ersetzt werden.

Die Frage, die dann gestellt werden sollte, lautet: "Verhält sich dies wie eine Konstante? Oder verhält es sich wie ein Feld zum einmaligen Schreiben?" - und dann den Konventionen entsprechend folgen. Der Lackmustest für eine solche Frage wäre "Wenn Sie das Objekt serialisieren würden, würden Sie das letzte Feld einschließen?" Wenn die Antwort lautet, dass es sich um eine Konstante handelt, behandeln Sie sie als solche (und serialisieren Sie sie nicht). Wenn es jedoch Teil des Status des Objekts ist, der serialisiert werden müsste, ist es keine Konstante.

In jedem Fall ist es wichtig, sich an den Codestil zu halten, egal wie richtig oder falsch er ist. Schlimmeres Problem entsteht durch inkonsistente Konventionen innerhalb eines Projekts als nur etwas, das das Auge beleidigt. Erwägen Sie, einige statische Analysetools zu erwerben und diese so zu konfigurieren, dass die Konsistenz erhalten bleibt.

20
user40980

BAR_BATZ ist in diesem Beispiel keine Konstante. Die Konstruktoren von Foo können es auf Objektebene auf unterschiedliche Werte setzen. Zum Beispiel

public class Foo {
    private final String BAR_BATZ;

    Foo() {
       BAR_BATZ = "ascending";
    } 

    Foo(String barBatz) {
       BAR_BATZ = barBatz;
    }
}
5
Kirby