编码约定 - 命名枚举

280 java standards coding-style

是否存在在Java中命名枚举的约定?

我的偏好是枚举是一种类型.所以,例如,你有一个枚举

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

NetworkConnectionType{LAN,Data_3g,Data_4g, ... }
Run Code Online (Sandbox Code Playgroud)

我反对命名它:

FruitEnum
NetworkConnectionTypeEnum
Run Code Online (Sandbox Code Playgroud)

我知道很容易找出哪些文件是枚举,但是你也可以:

NetworkConnectionClass
FruitClass
Run Code Online (Sandbox Code Playgroud)

另外,是否有一个好的文档描述了常量,在哪里声明它们等等?

DJC*_*rth 452

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

enum Fruit {APPLE, ORANGE, BANANA, PEAR};
Run Code Online (Sandbox Code Playgroud)

没有理由比FruitClass更多地编写FruitEnum.你只是在浪费四个(或五个)字符而不添加任何信息.

Java本身推荐这种方法,并在它们的示例中使用它.

  • 不,枚举实例是一个实例.枚举是一个类. (80认同)
  • @Walter为什么要使枚举实例看起来像是一个类增强可读性? (37认同)
  • 我命名为Fruit.APPLE.chew()的命名模式的想法确实让我感到困惑.此外,虽然这是一个非常糟糕的做法,但APPLE并不一定是常数(不可变).随着枚举到完整的java类我不确定使用为c甚至不存在的东西开发的约定(对象,而不是枚举)总是有意义的 (28认同)
  • 我开始以这种方式命名我的枚举,但为了便于阅读,我现在使用的是Fruit.Apple而不是Fruit.APPLE. (21认同)
  • 从技术上讲,枚举实例_are_类.这就是他们可以拥有方法的原因. (16认同)
  • 仅供将来参考,[java people agree](http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html):`因为它们是常量,枚举类型字段的名称是大写字母 (16认同)
  • APPLE不代表*an*apple,它代表APPLE类型.(我们知道这是因为只有一个APPLE).你不应该咀嚼这种类型,你应该咀嚼一个类Apple的实例(可能有一个类型指示器APPLE). (13认同)
  • @Hardcoded,我完全同意所有****除了**暗示"静态最终"立即属于"常量"的约定.拥有一个本身可变的`static final`变量是完全合法的; 例如,`static final List <String> sSeenItems`被声明为`static final`,因此它的*reference*不能改变; 但你**仍然可以`add()`,`remove()`,`clear()`等等; 因此它*不是恒定的*. (5认同)
  • @DJClayworth - "不,枚举实例是一个实例.枚举是一个类",如果你的枚举实例上有方法,那么就会生成像"Fruit $ 1.class"这样的文件(否则它们不会生成).因此,如果他们是类或只是实例取决于枚举实例是否有方法. (4认同)
  • 使用大写枚举值的另一个理由是它们可以使用`Fruit.valueOf(fruitString.toUpperCase())`.(由于[valueOf](http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html)区分大小写,因此混合大小写枚举值需要自定义代码才能执行此操作.) (4认同)
  • @BillK就个案而言,我个人并没有受到'Fruit.APPLE.chew()`的困扰.APPLE是一个不变的参考,帽子对我来说很好.也许你只是不习惯看到常量引用,因为我们大多使用常量基元.我们还应该使用`private static final Logger LOG = ...;`. (3认同)
  • 想想`... {APPLE,...`as:`static final Fruit APPLE = new Fruit();`该字段的声明是静态final,因此它属于常量约定.在Enum中不应该有太多可变的东西,否则你的代码会发臭!枚举应该只是一组(静态)预定义值. (2认同)
  • @DJClayworth *“ APPLE不代表苹果,它代表APPLE类型。” *-尽管我同意100%的回答,但我不同意这句话。APPLE不是类型,APPLE是Fruit的实例,它是Fruit的少数实例之一,以有限的数量存在。 (2认同)
  • 怎么样[Collector.Characteristics](https://docs.oracle.com/javase/8/docs/api/java/util/stream/Collector.Characteristics.html)? (2认同)

Sta*_*Log 76

这可能不会让我成为很多新朋友,但应该补充说C#人有不同的指导方针:枚举实例是"Pascal case"(大小写混合).请参阅stackoverflow讨论MSDN枚举类型命名准则.

当我们与C#系统交换数据时,我很想完全复制它们的枚举,而忽略了Java的"常量具有大写名称"约定.考虑到这一点,我没有看到枚举实例限制为大写的重要性.出于某些目的,.name()是获取枚举常量的可读表示的便捷快捷方式,并且混合大小写的名称看起来更好.

所以,是的,我敢于质疑Java枚举命名约定的价值."编程世界的另一半"确实使用了不同的风格这一事实让我觉得怀疑我们自己的宗教是合法的.

  • C#是一种非常好的语言,但这简直太愚蠢了.*C#中的所有*都是非常常见的情况,基本上与没有命名约定相同; 通过查看名字,你什么都得不到.你无法分辨它是一个类,方法,属性等. (11认同)
  • **TIL**只有Java或C#程序员才是真正的程序员,他们的数字是相同的.#讽刺 (5认同)
  • 此外,布尔值实际上是一个枚举,实例为true和false(小写)。因此,是的,所有上限都很丑陋。 (3认同)

beo*_*ign 22

如前所述,根据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;
}
Run Code Online (Sandbox Code Playgroud)

根据惯例,它应该看起来像:

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;
    }
}
Run Code Online (Sandbox Code Playgroud)

因此,即便是甲骨文公司的人也有时会以方便的方式进行交易.

  • 这里枚举的名称也是错误的。它必须是 PropertyKey 而不是 PropertyKeys,因为这种类型的变量仅代表一个键。 (5认同)

Jim*_*m B 13

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

所以对于你的Fruit例子,我们会有一个Fruit类,在里面有一个名为Fruits的Enum.

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

常量沿着同一行,它们要么在它们相关的类中定义(所以类似Fruit.ORANGE_BUSHEL_SIZE); 或者,如果它们在名为"ConstantManager"(或等效的;类似ConstantManager.NULL_INT)的类中应用系统范围(即ints的等效"null值" ).(旁注;我们所有常量都是大写)

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

  • `Fruit.Fruits.Apple`对我来说太冗长了,字面意思是破坏DRY原则:-)我更喜欢例如`Fruit.Type.APPLE`. (8认同)
  • 我想补充说,现在似乎对象工厂使用复数命名,例如`Lists`和`Maps`.在我看来,这是一个很好的约定,我完全支持它更广泛的使用. (5认同)
  • 我不喜欢这种方法.这个名字的方式,苹果要么是一个水果,要么至少令人困惑,因为不清楚苹果是不是一个水果.我喜欢Peter的Type示例.至少那时它自我记录APPLE是一种水果类型.虽然整个水果的例子闻起来有点腐烂...... (2认同)

Bil*_*ard 7

它们仍然是类型,所以我总是使用我用于类的相同命名约定.

我绝对不赞成将"Class"或"Enum"放在一个名字中.如果你同时拥有一个FruitClass和一个FruitEnum其他东西是错误的,你需要更多的描述性名称.我试图考虑导致需要两者的代码类型,似乎应该有一个Fruit带有子类型而不是枚举的基类.(这只是我自己的猜测,你可能会遇到与我想象的情况不同的情况.)

我可以找到命名常量的最佳参考来自变量教程:

如果您选择的名称只包含一个单词,则以全小写字母拼写该单词.如果它由多个单词组成,则将每个后续单词的首字母大写.名称gearRatio和currentGear是此约定的主要示例.如果变量存储常量值,例如static final int NUM_GEARS = 6,则约定会略有变化,将每个字母大写并用后缀字符分隔后续单词.按照惯例,下划线字符从未在别处使用过.