编码约定-命名枚举

在Java中有命名枚举的约定吗?

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

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


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

我反对将其命名为:

FruitEnum
NetworkConnectionTypeEnum

我知道这很容易挑选出哪些文件是枚举，但你也会有:

NetworkConnectionClass
FruitClass

此外，是否有一个好的文档描述相同的常量，在哪里声明它们，等等?

265594 次浏览
小开

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

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

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

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

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

小开

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

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

我能找到的命名常量的最佳引用来自变量教程:

如果您选择的名称只包含一个单词，请将该单词全部拼写为小写字母。如果包含多个单词，则后面每个单词的首字母大写。名称gearRatio和currentGear是这种约定的主要例子。如果变量存储的是一个常量值，比如static final int NUM_GEARS = 6，则惯例略有变化，每个字母都大写，后面的单词用下划线分隔。按照惯例，下划线字符永远不会在其他地方使用。

小开
最佳答案

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

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

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

小开 
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中已经被广泛使用了，但它并不令人困惑，只是有点不合时宜。


提交答案