枚举类型命名 Java,关于java：编码约定-命名枚举

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

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

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

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

我反对命名：

FruitEnum

NetworkConnectionTypeEnum

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

NetworkConnectionClass

FruitClass

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

请使其成为社区Wiki。 由于没有一个可接受的答案，否则它将被关闭。

@Alexander Pogrebnyak不，有一个答案。

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

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

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

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

我以这种方式开始命名枚举，但是为了便于阅读，我现在使用的是Fruit.Apple而不是Fruit.APPLE。

@Walter为什么使枚举实例看起来像是一个类可以提高可读性？

从技术上讲，枚举实例是类。这就是为什么他们可以有方法的原因。

不，枚举实例是一个实例。枚举是一类。

使我键入Fruit.APPLE.chew()的命名模式的想法确实使我很烦。同样，尽管这将是非常糟糕的做法，但APPLE不必一定是常量(不可变)。随着将枚举提升为完整的Java类，我不确定使用针对c中根本不存在的东西(对象，而不是枚举)开发的约定总是有意义的

鉴于枚举的实例是具有公共访问权限的实例，为什么不遵循实例命名惯例？例如Fruit.apple，Color.blue等。我同意Bill K的说法，Fruit.APPLE.chew()确实令人困惑。

APPLE不代表苹果，它代表APPLE类型。 (我们知道这一点，因为只能有一个APPLE)。您不应该咀嚼类型，而应该咀嚼Apple类的实例(可能具有类型指示器APPLE)。

仅供以后参考，Java人士同意：Because they are constants, the names of an enum types fields are in uppercase letters.

@DJClayworth-"不，一个枚举实例是一个实例。一个枚举是一个类"，如果您的枚举实例上有方法，则将生成" Fruit $ 1.class"之类的文件(否则它们就不会产生)。因此，它们是类还是实例取决于枚举实例是否具有方法。

@DJClayworth"您不应该咀嚼类型..."是。应该向枚举提交有意义的方法。像Fruit＃hasPits。因此，如果某些食物恰好被分配了APPLE枚举，则可以确定它是否有坑。

使用大写枚举值的另一个参数是可以使用Fruit.valueOf(fruitString.toUpperCase())。 (由于valueOf是区分大小写的，因此大小写混合的枚举值将需要自定义代码来执行此操作。)

将...{APPLE,...视为：static final Fruit APPLE = new Fruit();字段的声明是静态的final，因此它属于常量的约定。枚举中不应有太多可变的东西，否则您的代码会发臭！枚举应仅是一组(静态)预定义值。

@硬编码，我全心全意地同意所有内容，只是暗示static final立即属于"常量"的含义。拥有一个本身可变的static final变量是完全合法的。例如，static final ListsSeenItems被声明为static final，因此其引用不能更改；但您仍然可以add()，remove()，clear()等；因此它不是恒定的。

问题不是常量的约定，而是常量的定义。原始的Java编码标准实际上是这样做的，并且声明了任何后跟一个。不是一个常数。基本上，仅最终静态文字遵循此约定。 CAPS.someMethod()很丑陋，通常不应该使用INMHO。

@Joe列表变量本身是一个常量，因为引用的列表始终相同。当然，您可以更改列表中的内容，但这远不是干净的代码，并且可能是Mindprods"无法维护的代码"的主意

@DJClayworth" APPLE不代表苹果，它代表APPLE类型。" -尽管我同意您100％的回答，但我还是不同意这句话。 APPLE不是类型，APPLE是Fruit的实例，它是Fruit的少数实例之一，以有限的数量存在。

@BillK Im个人不因大小写而受Fruit.APPLE.chew()困扰。 APPLE是常量参考，上限对我来说很好。也许您只是不习惯看到常量引用，因为我们大多使用常量原语。我们也应该使用private static final Logger LOG = ... ;。

@RyanShillington，但实例命名惯例受到尊重。常量实例是大写字母，变量实例是小写驼峰：stackoverflow.com/a/7259738/1540818

如果要可靠地将枚举与类区分开，则可以调整IDE使其格式不同。在我的环境中，枚举，类和接口分别是不同的紫色。

收集器特性如何？

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

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

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

+1：怀疑我们自己的宗教

直到只有Java或C＃程序员才是真正的程序员，并且他们的人数相等。 ＃讽刺

而且，所有的帽子看起来都很丑...

C＃是另外一种很棒的语言，但这简直是愚蠢的。在C＃中，一切几乎都是Pascal情况，基本上与根本没有命名约定的情况相同；看名字你一无所获。您无法确定其是否为类，方法，属性等。

此外，布尔值实际上是一个枚举，实例为true和false(小写)。因此，是的，所有上限都很丑陋。

@FlorianF，请勿将主要类型boolean与Boolean类(docs.oracle.com/javase/7/docs/api/java/lang/Boolean.html)混淆。该类确实使用大写约定

如前所述，根据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。

我想补充一点，看来如今对象工厂是使用复数形式命名的，例如Lists和Maps。我认为这是一个很好的约定，我完全支持它的更广泛使用。

是的，它们类似于我的个人编码标准，但不同于我的工作场所编码标准。我们没有很多工作标准，因此我试图寻找一个好的文档作为参考。

Fruit.Fruits.Apple对我来说太冗长，从字面上打破了DRY原则:-)我更喜欢例如Fruit.Type.APPLE。

我不喜欢这种方法。苹果的命名方式要么是"水果"，要么至少是令人困惑的，因为不清楚苹果不是"水果"。我喜欢Peters Type的例子。至少然后它的自我证明APPLE是一种水果。虽然这整个水果的例子闻起来有点烂...

我也不喜欢这样。如果"水果"类代表一个水果(并且应该)，那么"水果"可以代表什么？如果Fruit(该类)确实是处理Fruit的类，则应将其重命名为" FruitHandler或FruitManager。

我同意Mark＆DJ的观点：在您的示例中，它看起来不错，但是Fruits fruits = Fruits.APPLE;当然不是。

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

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

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

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.

命名常量的参考位于oracle.com/technetwork/java/javase/documentation/

如果我可以添加$ 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 }

}

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