編碼約定 - 命名枚舉

Question

是否存在在Java中命名枚舉的約定？

我的偏好是枚舉是一種類型。 所以，例如，你有一個枚舉

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

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

我反對命名它：

FruitEnum
NetworkConnectionTypeEnum

我知道很容易找出哪些文件是枚舉，但是你也可以：

NetworkConnectionClass
FruitClass

另外，是否有一個好的文檔描述了常量，在哪里聲明它們等等？

Answer 1

枚舉是類，應遵循類的約定。 枚舉的實例是常量，應遵循常量的約定。 所以

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

沒有理由比FruitClass更多地編寫FruitEnum。 你只是在浪費四個（或五個）字符而不添加任何信息。

Java本身推薦這種方法，並在它們的示例中使用它。

Answer 2

這可能不會讓我成為很多新朋友，但應該補充一點，C＃人有不同的准則：枚舉實例是“Pascal case”（大小寫混合）。 請參閱stackoverflow討論和MSDN枚舉類型命名准則 。

當我們與C＃系統交換數據時，我很想完全復制它們的枚舉，而忽略了Java的“常量具有大寫名稱”約定。 考慮到這一點，我沒有看到枚舉實例限制為大寫的重要性。 出於某些目的，.name（）是獲取枚舉常量的可讀表示的便捷快捷方式，並且混合大小寫的名稱看起來更好。

所以，是的，我敢於質疑Java枚舉命名約定的價值。 “編程世界的另一半”確實使用了不同的風格這一事實讓我覺得懷疑我們自己的宗教是合法的。

Answer 3

如前所述，根據Oracle網站上的文檔（ http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html ），枚舉實例應為大寫。

但是，在查看Oracle網站（ http://www.oracle.com/technetwork/java/javaee/downloads/index.html ）上的JavaEE7教程時，我偶然發現了“杜克的書店”教程和課堂（ tutorial\\examples\\case-studies\\dukes-bookstore\\src\\main\\java\\javaeetutorial\\dukesbookstore\\components\\AreaComponent.java ），我找到了以下枚舉定義：

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

根據慣例，它應該看起來像：

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

因此，即便是甲骨文公司的人也有時會以方便的方式進行交易。

Answer 4

在我們的代碼庫中; 我們通常在它們所屬的類中聲明枚舉。

所以對於你的Fruit例子，我們會有一個Fruit類，在里面有一個名為Fruits的Enum。

在代碼中引用它如下所示： Fruit.Fruits.Apple, Fruit.Fruits.Pear等。

常量沿着同一行，它們要么在它們相關的類中定義（所以類似於Fruit.ORANGE_BUSHEL_SIZE ）; 或者它們是否在名為“ConstantManager”的類（或類似的;類似於ConstantManager.NULL_INT ）中應用系統范圍（即int的等效“null值”）。 （旁注;我們所有常量都是大寫）

與往常一樣，您的編碼標准可能與我的不同; 所以YMMV。

Answer 5

它們仍然是類型，所以我總是使用我用於類的相同命名約定。

我絕對不贊成將“Class”或“Enum”放在一個名字中。 如果你同時擁有FruitClass和FruitEnum那么其他東西就錯了，你需要更多的描述性名稱。 我正在嘗試考慮那些導致需要兩者的代碼，似乎應該有一個帶有子類型而不是枚舉的Fruit基類。 （這只是我自己的猜測，你可能會遇到與我想象的情況不同的情況。）

我可以找到命名常量的最佳參考來自變量教程 ：

如果您選擇的名稱只包含一個單詞，則以全小寫字母拼寫該單詞。 如果它由多個單詞組成，則將每個后續單詞的首字母大寫。 名稱gearRatio和currentGear是此約定的主要示例。 如果變量存儲常量值，例如static final int NUM_GEARS = 6，則約定會略有變化，將每個字母大寫並用后綴字符分隔后續單詞。 按照慣例，下划線字符從未在別處使用過。

Answer 6

enum MyEnum {VALUE_1,VALUE_2}

是（大約）喜歡說

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 }
}

所以我猜全部大寫是嚴格的更正確，但我仍然使用類名約定，因為我討厭所有大寫的地方

Answer 7

如果我可以添加我的$ 0.02，我更喜歡使用PascalCase作為C中的枚舉值。

在C中，它們基本上是全局的，並且PEER_CONNECTED變得非常累，而不是PeerConnected。

呼吸新鮮空氣。

從字面上看，它讓我更容易呼吸。

在Java中，只要您從另一個類靜態導入它們，就可以使用原始枚舉名稱。

import static pkg.EnumClass.*;

現在，您可以使用已經以不同方式限定的非限定名稱。

我目前（思考）將一些C代碼移植到Java並且當前在選擇Java約定（更冗長，更冗長，更丑陋）和我的C風格之間“撕裂”。

PeerConnected將變為PeerState.CONNECTED，但在switch語句中，它是CONNECTED。

現在對於后一種慣例有很多話要說它確實看起來不錯但是某些“慣用語”如if (s == PeerAvailable)變得像if (s == PeerState.AVAILABLE)和懷舊，這是意義的喪失對我來說。

我認為我仍然更喜歡Java風格，但是我很難看到尖叫的代碼。

現在我意識到PascalCase已經在Java中被廣泛使用，但是它實際上並不是很混亂，只是有點不合適。