[英]Coding Conventions - Naming Enums
是否存在在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 case”(大小写混合)。 请参阅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教程时,我偶然发现了“杜克的书店”教程和课堂( 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;
}
}
因此,即便是甲骨文公司的人也有时会以方便的方式进行交易。
在我们的代码库中; 我们通常在它们所属的类中声明枚举。
所以对于你的Fruit例子,我们会有一个Fruit类,在里面有一个名为Fruits的Enum。
在代码中引用它如下所示: Fruit.Fruits.Apple, Fruit.Fruits.Pear
等。
常量沿着同一行,它们要么在它们相关的类中定义(所以类似于Fruit.ORANGE_BUSHEL_SIZE
); 或者它们是否在名为“ConstantManager”的类(或类似的;类似于ConstantManager.NULL_INT
)中应用系统范围(即int的等效“null值”)。 (旁注;我们所有常量都是大写)
与往常一样,您的编码标准可能与我的不同; 所以YMMV。
它们仍然是类型,所以我总是使用我用于类的相同命名约定。
我绝对不赞成将“Class”或“Enum”放在一个名字中。 如果你同时拥有FruitClass
和FruitEnum
那么其他东西就错了,你需要更多的描述性名称。 我正在尝试考虑那些导致需要两者的代码,似乎应该有一个带有子类型而不是枚举的Fruit
基类。 (这只是我自己的猜测,你可能会遇到与我想象的情况不同的情况。)
我可以找到命名常量的最佳参考来自变量教程 :
如果您选择的名称只包含一个单词,则以全小写字母拼写该单词。 如果它由多个单词组成,则将每个后续单词的首字母大写。 名称gearRatio和currentGear是此约定的主要示例。 如果变量存储常量值,例如static final int NUM_GEARS = 6,则约定会略有变化,将每个字母大写并用后缀字符分隔后续单词。 按照惯例,下划线字符从未在别处使用过。
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中的枚举值。
在C中,它们基本上是全局的,并且PEER_CONNECTED变得非常累,而不是PeerConnected。
呼吸新鲜空气。
从字面上看,它让我更容易呼吸。
在Java中,只要您从另一个类静态导入它们,就可以使用原始枚举名称。
import static pkg.EnumClass.*;
现在,您可以使用已经以不同方式限定的非限定名称。
我目前(思考)将一些C代码移植到Java并且当前在选择Java约定(更冗长,更冗长,更丑陋)和我的C风格之间“撕裂”。
PeerConnected将变为PeerState.CONNECTED,但在switch语句中,它是CONNECTED。
现在对于后一种惯例有很多话要说它确实看起来不错但是某些“惯用语”如if (s == PeerAvailable)
变得像if (s == PeerState.AVAILABLE)
和怀旧,这是意义的丧失对我来说。
我认为我仍然更喜欢Java风格,但是我很难看到尖叫的代码。
现在我意识到PascalCase已经在Java中被广泛使用,但是它实际上并不是很混乱,只是有点不合适。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.