编码约定-命名枚举

是否有使用Java命名枚举的约定？

我的偏好是枚举是一种类型。例如，您有一个枚举

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

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

我反对为其命名：

FruitEnum
NetworkConnectionTypeEnum

我知道很容易挑选出哪些文件是枚举，但随后您还将拥有：

NetworkConnectionClass
FruitClass

另外，是否有一个很好的文档对常量进行了描述，在何处声明了常量等？

枚举是类，应遵循类的约定。枚举的实例是常量，应遵循常量的约定。所以

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

除了FruitClass之外，没有其他理由编写FruitEnum了。您只是浪费了四个（或五个）不添加任何信息的字符。

Java本身推荐这种方法，并在示例中使用了这种方法。

这可能不会让我结识很多新朋友，但应该补充一点，C＃员工有不同的准则：枚举实例为“ Pascal大小写”（大小写混合）。请参阅stackoverflow讨论和MSDN枚举类型命名准则。

当我们与C＃系统交换数据时，我很想完全复制它们的枚举，而忽略了Java的“常量具有大写名称”约定。考虑一下，对于枚举实例，将其限制为大写并没有太大价值。出于某种目的，.name（）是获取枚举常量可读形式的方便快捷方式，混合大小写的名称看起来更好。

因此，是的，我敢于质疑Java枚举命名约定的价值。“编程世界的另一半”确实使用了不同的风格，这一事实使我认为怀疑我们自己的宗教信仰是合理的。

如前所述，根据Oracle网站（http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html）上的文档，枚举实例应为大写。

但是，在浏览Oracle网站（http://www.oracle.com/technetwork/java/javaee/downloads/index.html）上的JavaEE7教程时，我偶然发现了“ Duke's bookstore”教程和一个类（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;
    }
}

因此，即使是Oracle的员工有时也会很方便地进行交易约定。

在我们的代码库中；我们通常在它们所属的类中声明枚举。

因此，对于您的Fruit实例，我们将有一个Fruit类，并且在其中有一个名为Fruits的枚举。

在代码中引用它看起来像这样： Fruit.Fruits.Apple, Fruit.Fruits.Pear等。

常量遵循同一行，它们要么在与它们相关的类中定义（例如Fruit.ORANGE_BUSHEL_SIZE）；或者它们是否在名为“ ConstantManager”（或等价物；如ConstantManager.NULL_INT）的类中应用系统范围（即int的等价“空值” ）。（旁注；我们所有的常数都大写）

和往常一样，您的编码标准可能与我的不同。YMMV。

它们仍然是类型，因此我始终使用与类相同的命名约定。

我绝对不会在名称中加上“ Class”或“ Enum”。如果您同时拥有a FruitClass和a，FruitEnum那么其他地方就不对了，您需要更具描述性的名称。我正在尝试考虑导致同时需要两者的代码类型，并且似乎应该有一个Fruit带有子类型而不是枚举的基类。（尽管这只是我自己的推测，但您可能遇到的情况与我想象的情况有所不同。）

我可以找到的有关命名常量的最佳参考来自“ 变量”教程：

如果您选择的名称仅包含一个单词，则用所有小写字母拼写该单词。如果它包含多个单词，请大写每个后续单词的第一个字母。名称gearRatio和currentGear是此约定的主要示例。如果您的变量存储了一个常量值，例如static final int NUM_GEARS = 6，则约定会稍有变化，将每个字母大写并用下划线字符分隔后续单词。按照惯例，下划线字符永远不会在其他地方使用。

如果我可以添加$ 0.02，则我更喜欢使用PascalCase作为C中的枚举值。

在C语言中，它们基本上是全局的，与PeerConnected相反，PEER_CONNECTED确实很累。

呼吸新鲜空气。

从字面上看，它使我呼吸更轻松。

在Java中，只要您从其他类静态导入原始枚举名称，就可以使用原始枚举名称。

import static pkg.EnumClass.*;

现在，您可以使用已经以其他方式进行限定的非限定名称。

我目前（正在考虑）将某些C代码移植到Java，并且目前在选择Java约定（更冗长，更冗长和更丑陋）和我的C风格之间“折腾”。

PeerConnected将变为PeerState.CONNECTED，除非在switch语句中为CONNECTED。

对于后一种约定，现在有很多话要说，它看起来确实不错，但是某些“惯用语”（例如if (s == PeerAvailable)变得像if (s == PeerState.AVAILABLE)老式的一样）对我来说却失去了意义。

我想我还是喜欢Java风格，因为它很清晰，但是我很难看清楚尖叫的代码。

现在我意识到PascalCase已经在Java中被广泛使用，但实际上并没有使它感到困惑，只是有点地方。

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

所以我猜所有大写字母严格来说是更正确的，但是我仍然使用类名约定，因为我讨厌任何地方的所有大写字母