Codierungskonventionen - Namensnennungen

Gibt es eine Konvention zum Benennen von Aufzählungen in Java?

Ich bevorzuge, dass eine Aufzählung ein Typ ist. So haben Sie zum Beispiel eine Aufzählung

Fruit{Apple,Orange,Banana,Pear, ... }

NetworkConnectionType{LAN,Data_3g,Data_4g, ... }

Ich bin dagegen, es zu benennen:

FruitEnum
NetworkConnectionTypeEnum

Ich verstehe, es ist einfach herauszufinden, welche Dateien Aufzählungen sind, aber dann hätten Sie auch:

NetworkConnectionClass
FruitClass

Gibt es auch ein gutes Dokument, das dasselbe für Konstanten beschreibt, wo sie deklariert werden sollen usw.?

Aufzählungen sind Klassen und sollten den Konventionen für Klassen folgen. Instanzen einer Aufzählung sind Konstanten und sollten den Konventionen für Konstanten folgen. Damit

enum Fruit {APPLE, ORANGE, BANANA, PEAR};

Es gibt keinen Grund mehr, FruitEnum zu schreiben als FruitClass. Sie verschwenden nur vier (oder fünf) Zeichen, die keine Informationen hinzufügen.

Java selbst empfiehlt diesen Ansatz und wird in ihren Beispielen verwendet .

Dies wird mich wahrscheinlich nicht zu vielen neuen Freunden machen, aber es sollte hinzugefügt werden, dass die C # -Leute eine andere Richtlinie haben: Die Enum-Instanzen sind "Pascal-Großbuchstaben" (Groß- / Kleinschreibung gemischt). Siehe Diskussion über den Stapelüberlauf und Richtlinien zur Benennung von MSDN-Aufzählungstypen .

Während wir Daten mit einem C # -System austauschen, bin ich versucht, ihre Aufzählungen genau zu kopieren, wobei ich Javas Konvention "Konstanten haben Großbuchstaben" ignoriere. Wenn ich darüber nachdenke, sehe ich nicht viel Wert darin, für Enum-Instanzen auf Großbuchstaben beschränkt zu sein. Für einige Zwecke ist .name () eine praktische Verknüpfung, um eine lesbare Darstellung einer Enum-Konstante zu erhalten, und ein gemischter Fallname würde besser aussehen.

Also, ja, ich wage es, den Wert der Java-Enum-Namenskonvention in Frage zu stellen. Die Tatsache, dass "die andere Hälfte der Programmierwelt" tatsächlich einen anderen Stil verwendet, lässt mich denken, dass es legitim ist, an unserer eigenen Religion zu zweifeln.

Wie bereits erwähnt, sollten Enum-Instanzen gemäß den Dokumenten auf der Oracle-Website in Großbuchstaben geschrieben werden ( http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html ) .

Beim Durchsehen eines JavaEE7-Tutorials auf der Oracle-Website ( http://www.oracle.com/technetwork/java/javaee/downloads/index.html ) bin ich jedoch auf das Tutorial "Duke's Bookstore" und auf eine Klasse gestoßen ( tutorial\examples\case-studies\dukes-bookstore\src\main\java\javaeetutorial\dukesbookstore\components\AreaComponent.java) Fand ich folgende Aufzählungsdefinition:

private enum PropertyKeys {
    alt, coords, shape, targetImage;
}

Nach den Konventionen hätte es so aussehen sollen:

public enum PropertyKeys {
    ALT("alt"), COORDS("coords"), SHAPE("shape"), TARGET_IMAGE("targetImage");

    private final String val;

    private PropertyKeys(String val) {
        this.val = val;
    }

    @Override
    public String toString() {
        return val;
    }
}

Es scheint also, dass sogar die Mitarbeiter von Oracle Konventionen manchmal bequem handeln.

In unserer Codebasis; Wir deklarieren normalerweise Aufzählungen in der Klasse, zu der sie gehören.

Für Ihr Fruchtbeispiel hätten wir also eine Obstklasse und darin eine Aufzählung namens Früchte.

Die Referenzierung im Code sieht folgendermaßen aus: Fruit.Fruits.Apple, Fruit.Fruits.Pearusw.

Konstanten folgen der gleichen Linie, wo sie entweder in der Klasse definiert werden, für die sie relevant sind (also so etwas wie Fruit.ORANGE_BUSHEL_SIZE); oder wenn sie systemweit (dh einen äquivalenten "Nullwert" für Ints) in einer Klasse mit dem Namen "ConstantManager" (oder einem Äquivalent; wie ConstantManager.NULL_INT) angewendet werden . (Randnotiz; alle unsere Konstanten sind in Großbuchstaben)

Wie immer unterscheiden sich Ihre Codierungsstandards wahrscheinlich von meinen. also YMMV.

Sie sind immer noch Typen, daher verwende ich immer die gleichen Namenskonventionen, die ich für Klassen verwende.

Ich würde definitiv die Stirn runzeln, wenn ich "Class" oder "Enum" in einen Namen stecke. Wenn Sie sowohl ein FruitClassals auch ein FruitEnumhaben, stimmt etwas anderes nicht und Sie benötigen aussagekräftigere Namen. Ich versuche über die Art von Code nachzudenken, die dazu führen würde, dass beides benötigt wird, und es scheint, als sollte es einen gebenFruit Basisklasse mit Untertypen anstelle einer Aufzählung geben sollte. (Das ist nur meine eigene Spekulation, vielleicht haben Sie eine andere Situation als ich mir vorstelle.)

Die beste Referenz, die ich zum Benennen von Konstanten finden kann, stammt aus dem Variablen-Tutorial :

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 speichert, z. B. static final int NUM_GEARS = 6, ä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.

Wenn ich meine $ 0.02 hinzufügen kann, bevorzuge ich die Verwendung von PascalCase als Aufzählungswerte in C.

In C sind sie im Grunde genommen global und PEER_CONNECTED wird im Gegensatz zu PeerConnected sehr anstrengend.

Hauch frischer Luft.

Es erleichtert mir buchstäblich das Atmen.

In Java ist es möglich, unformatierte Aufzählungsnamen zu verwenden, solange Sie sie statisch aus einer anderen Klasse importieren.

import static pkg.EnumClass.*;

Jetzt können Sie die nicht qualifizierten Namen verwenden, die Sie bereits auf andere Weise qualifiziert haben.

Ich denke gerade darüber nach, C-Code nach Java zu portieren, und bin derzeit zwischen der Wahl der Java-Konvention (die ausführlicher, langwieriger und hässlicher ist) und meinem C-Stil hin und her gerissen.

PeerConnected wird zu PeerState.CONNECTED, außer in switch-Anweisungen, in denen es CONNECTED ist.

Jetzt gibt es viel zu sagen für die letztere Konvention und es sieht gut aus, aber bestimmte "idiomatische Phrasen" wie if (s == PeerAvailable)wie if (s == PeerState.AVAILABLE)und nostalgisch werden, das ist ein Bedeutungsverlust für mich.

Ich glaube, ich bevorzuge aus Gründen der Klarheit immer noch den Java-Stil, aber es fällt mir schwer, den schreienden Code zu betrachten.

Jetzt ist mir klar, dass PascalCase in Java bereits weit verbreitet ist, aber sehr verwirrend wäre es nicht wirklich, nur ein bisschen fehl am Platz.

enum MyEnum {VALUE_1,VALUE_2}

ist (ungefähr) wie zu sagen

class MyEnum {

    public static final MyEnum VALUE_1 = new MyEnum("VALUE_1");
    public static final MyEnum VALUE_2 = new MyEnum("VALUE_2");

    private final name;

    private MyEnum(String name) {
        this.name = name;
    }

    public String name() { return this.name }
}

Ich denke, die Großbuchstaben sind streng korrekter, aber ich verwende immer noch die Klassennamenkonvention, da ich alle Großbuchstaben überall hasse