Соглашения о кодировании - перечисления имен


289

Существует ли соглашение по именованию перечислений в Java?

Я предпочитаю, чтобы enum был типом. Так, например, у вас есть перечисление

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

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

Я против того, чтобы называть это:

FruitEnum
NetworkConnectionTypeEnum

Я понимаю, что легко определить, какие файлы являются перечислениями, но тогда у вас также будет:

NetworkConnectionClass
FruitClass

Кроме того, есть ли хороший документ, описывающий то же самое для констант, где их объявлять и т. Д.?


2
Пожалуйста, сделайте это вики-сообществом. Так как нет единого приемлемого ответа, и в противном случае он будет закрыт.
Александр Погребняк

13
@ Александр Погребняк Нет, ответ есть.
Том Хотин -

Ответы:


473

Перечисления являются классами и должны следовать соглашениям для классов. Экземпляры перечисления являются константами и должны следовать соглашениям для констант. Так

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

Нет оснований для написания FruitEnum больше, чем FruitClass. Вы просто тратите четыре (или пять) символов, которые не добавляют никакой информации.

Сама Java рекомендует этот подход, и он используется в их примерах .


22
Я начал называть свои перечисления таким образом, но для удобства чтения я теперь использую Fruit.Apple вместо Fruit.APPLE.

38
@Walter Почему создание экземпляра enum выглядит так, как будто это класс, улучшающий читабельность?
DJClayworth

17
Технически, экземпляры enum являются классами. Вот почему у них могут быть методы.
Тед Хопп

87
Нет, экземпляр enum является экземпляром. Перечисление - это класс.
DJClayworth

30
Идея шаблона именования, которая заставляет меня набирать Fruit.APPLE.chew (), действительно меня раздражает. Кроме того, хотя это было бы очень плохой практикой, APPLE не обязательно должен быть постоянным (неизменным). С продвижением перечислений до полных классов Java, я не уверен, что использование соглашений, разработанных для чего-то, чего даже не существует в c (объекты, а не перечисления), всегда имеет смысл
Bill K

76

Это, вероятно, не сделает меня большим количеством новых друзей, но следует добавить, что у людей на C # есть другое правило: экземпляры enum - это «регистр Паскаля» (смешанные прописные и строчные буквы). См StackOverflow обсуждение и MSDN Перечень Тип Правила именования .

Поскольку мы обмениваемся данными с системой C #, у меня возникает соблазн точно копировать их перечисления, игнорируя соглашение Java «константы имеют заглавные имена». Размышляя об этом, я не вижу особой ценности в том, чтобы ограничиваться прописными буквами для экземпляров enum. Для некоторых целей .name () - это удобный ярлык для получения удобочитаемого представления константы перечисления, а смешанное имя регистра будет выглядеть лучше.

Итак, да, я осмелюсь поставить под сомнение ценность соглашения об именовании перечислений Java. Тот факт, что «другая половина мира программирования» действительно использует другой стиль, заставляет меня думать, что законно сомневаться в нашей собственной религии.


7
TIL, что только программисты на Java или C # являются настоящими программистами и что их числа равны. #sarcasm
Mindwin

14
C # - отличный язык, но это просто глупо. В C # все довольно похоже на случай Паскаля, который в основном такой же, как и отсутствие соглашений об именах; вы ничего не получаете, глядя на имя. Вы не можете сказать, является ли это класс, метод, свойство и т. Д.
Bassinator

3
Кроме того, логическое значение - практически перечисление, экземпляры true и false в нижнем регистре. Так что да, все заглавные буквы ужасны.
Флориан Ф

@FlorianF, не путайте первичный тип boolean с классом Boolean ( docs.oracle.com/javase/7/docs/api/java/lang/Boolean.html ). класс использует прописные буквы
IvoC

24

Как уже говорилось, экземпляры enum должны быть прописными в соответствии с документацией на веб-сайте Oracle ( http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html ).

Однако, просматривая учебник по JavaEE7 на веб-сайте Oracle ( http://www.oracle.com/technetwork/java/javaee/downloads/index.html ), я наткнулся на учебник "Книжный магазин Герцога" и в классе ( 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 иногда обмениваются соглашениями с удобством.


13

В нашей кодовой базе; мы обычно объявляем перечисления в классе, к которому они принадлежат.

Итак, для вашего примера Fruit у нас будет класс Fruit, а внутри него Enum, называемый Fruits.

Ссылка в коде выглядит следующим образом: Fruit.Fruits.Apple, Fruit.Fruits.Pearи т. Д.

Константы следуют по той же линии, где они либо определяются в классе, к которому они относятся (так что-то вроде Fruit.ORANGE_BUSHEL_SIZE); или если они применяют общесистемный (то есть эквивалентное «нулевое значение» для целых чисел) в классе с именем «ConstantManager» (или эквивалентном, подобном ConstantManager.NULL_INT) (примечание; все наши константы в верхнем регистре)

Как всегда, ваши стандарты кодирования, вероятно, отличаются от моих; так что YMMV.


5
Я хочу добавить, что кажется, что фабрики объектов в настоящее время называются с использованием множественного числа, например Listsи Maps. На мой взгляд, это хорошее соглашение, и я полностью поддерживаю его более широкое использование.
Эско

Да, они похожи на мои личные стандарты кодирования, но отличаются от моих стандартов кодирования на рабочем месте. У нас не так много стандартов для работы, поэтому я пытаюсь найти хороший документ для использования в качестве справочного материала.

8
Fruit.Fruits.Appleслишком многословен для меня, буквально нарушая принцип СУХОЙ :-) Я бы предпочел, например Fruit.Type.APPLE.
Петер Тёрёк

2
Мне не нравится этот подход. Как это называется, Apple либо является фруктом, либо, по крайней мере, сбивает с толку, поскольку неясно, является ли Apple фруктом, а не фруктом. Мне нравится пример типа Питера. По крайней мере, тогда это само документирование того, что ЯБЛОКО - это фрукт. Хотя весь этот пример с фруктами пахнет гнилой ...
Марк Питерс

1
Мне тоже это не нравится. Если класс «Фрукты» представляет фрукт (и должен), то что может представлять «Фрукты»? Если Fruit (класс) действительно является классом для работы с Fruit, то его следует переименовать в «FruitHandler» или «FruitManager».
DJClayworth

7

Они по-прежнему являются типами, поэтому я всегда использую те же соглашения об именах, которые я использую для классов.

Я определенно нахмурился бы, указав "Class" или "Enum" в названии. Если у вас есть и a, FruitClassи a, FruitEnumзначит что-то не так, и вам нужно больше описательных имен. Я пытаюсь подумать о том, какой код может привести к необходимости того и другого, и кажется, что должен быть Fruitбазовый класс с подтипами вместо перечисления. (Это только мои собственные предположения, у вас может быть другая ситуация, чем я представляю.)

Лучшая ссылка, которую я могу найти для именования констант, взята из учебника по переменным :

Если выбранное вами имя состоит только из одного слова, пишите это слово строчными буквами. Если оно состоит из более чем одного слова, используйте заглавные буквы первой буквы каждого последующего слова. Названия gearRatio и currentGear являются основными примерами этого соглашения. Если ваша переменная хранит постоянное значение, такое как static final int NUM_GEARS = 6, соглашение меняется незначительно, используя заглавные буквы и разделяя последующие слова символом подчеркивания. По соглашению символ подчеркивания никогда не используется в другом месте.


Ссылка для именования констант находится по адресу oracle.com/technetwork/java/javase/documentation/…
Christoffer Hammarström

1

Если я могу добавить свои 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, но очень запутанно, что это не так, просто немного неуместно.


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

поэтому я предполагаю, что все заглавные буквы строго правильнее, но все же я использую соглашение об именах классов, так как я ненавижу все заглавные буквы везде, где

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.