Соглашения О Кодировании-Перечисления Имен

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

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

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

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

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

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

ссылка в коде выглядит так: Fruit.Fruits.Apple, Fruit.Fruits.Pear и т. д.

константы следуют по той же линии, где они либо определяются в классе, к которому они относятся (так что что-то вроде Fruit.ORANGE_BUSHEL_SIZE); или если они применяются во всей системе (т. е. эквивалентное "нулевое значение" для ints) в классе с именем "ConstantManager" (или эквивалент; like ConstantManager.NULL_INT). (Примечание стороны; все наши константы в верхнем регистре)

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

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

Я определенно нахмурился бы, поставив "класс" или "перечисление" в имени. Если у вас есть оба 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.*;

Теперь вы можете использовать неквалифицированные имена, которые вы квалифицировали в a уже по-другому.

В настоящее время я (думаю) о портировании некоторого кода C на Java и в настоящее время "разрываюсь" между выбором соглашения Java (которое является более подробным, более длинным и более уродливым) и моим стилем C.

PeerConnected станет PeerState.Подключен, за исключением операторов switch, где он подключен.

Теперь есть что сказать для последнего соглашения, и это выглядит красиво, но некоторые "идиоматические фразы", такие как if (s == PeerAvailable) стать как if (s == PeerState.AVAILABLE) и ностальгически, это потеря смысла для меня.

Я думаю, что все еще предпочитаю стиль Java из-за ясности, но мне трудно смотреть на кричащий код.

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