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

对于你的Fruit例子，我们会有一个Fruit类，里面有一个Enum叫做Fruits。

在代码中引用它是这样的:Fruit.Fruits。苹果,Fruit.Fruits。梨,等等。

常量遵循同样的原则，它们要么在与之相关的类中定义(比如Fruit.ORANGE_BUSHEL_SIZE);或者在名为“ConstantManager”的类中应用系统范围(即int的等效“空值”)(或等效;如ConstantManager.NULL_INT)。(注;所有常量都是大写的)

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

它们仍然是类型，所以我总是使用与类相同的命名约定。

我绝对不赞成在名字中加入“Class”或“Enum”。如果你同时有一个FruitClass和一个FruitEnum，那么就有问题了，你需要更多描述性的名字。我试图思考那种会导致两者都需要的代码，似乎应该有一个带有子类型的Fruit基类，而不是枚举。(不过这只是我自己的猜测，你的情况可能和我想象的不一样。)

我能找到的命名常量的最好参考来自Variables教程:

If the name you choose consists of only one word, spell that word in all lowercase letters. If it consists of more than one word, capitalize the first letter of each subsequent word. The names gearRatio and currentGear are prime examples of this convention. If your variable stores a constant value, such as static final int NUM_GEARS = 6, the convention changes slightly, capitalizing every letter and separating subsequent words with the underscore character. By convention, the underscore character is never used elsewhere.

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

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

没有理由写FruitEnum，也没有理由写FruitClass。你只是浪费了四个(或五个)字符，没有添加任何信息。

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’sbookstore”教程，在一个类(教程\示例\案例研究\ Duke -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;
    }
}

因此，似乎甲骨文公司的人有时也会用方便来交换惯例。

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

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

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

在C语言中，它们基本上是全局的，与PeerConnected相比，PEER_CONNECTED非常累人。

呼吸新鲜空气。

真的，它让我呼吸更轻松。

在Java中，只要从另一个类中静态导入原始enum名称，就可以使用它们。

import static pkg.EnumClass.*;

现在，你可以使用非限定名称，你已经用另一种方式限定了。

我目前(正在考虑)将一些C代码移植到Java，目前在选择Java惯例(更冗长、更冗长、更丑陋)和我的C风格之间“犹豫不决”。

PeerConnected将变成PeerState。CONNECTED, switch语句除外，此处为CONNECTED。

现在对于后一种约定有很多要说的，它确实看起来不错，但某些“惯用短语”，如if (s == PeerAvailable)变成了if (s == PeerState.AVAILABLE)，怀旧地说，这对我来说是没有意义的。

我想我仍然更喜欢Java风格，因为它清晰明了，但我很难看到那些令人尖叫的代码。

现在我意识到PascalCase在Java中已经被广泛使用了，但它并不令人困惑，只是有点不合时宜。