Konwencje kodowania - Nazwy enumów

Czy istnieje konwencja nazewnictwa wyliczeń w Javie?

Wolę, aby wyliczenie było rodzajem. Na przykład masz wyliczenie

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

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

Jestem przeciwny nadaniu jej nazwy:

FruitEnum
NetworkConnectionTypeEnum

Rozumiem, że łatwo jest wybrać, które pliki są wyliczeniami, ale wtedy miałbyś również:

NetworkConnectionClass
FruitClass

Czy jest też dobry dokument opisujący to samo dla stałych, gdzie je zadeklarować itp.?

Wyliczenia są klasami i powinny być zgodne z konwencjami dla klas. Wystąpienia wyliczenia są stałymi i powinny być zgodne z konwencjami dla stałych. Więc

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

Nie ma powodu, aby pisać FruitEnum bardziej niż FruitClass. Po prostu marnujesz cztery (lub pięć) znaków, które nie dodają żadnych informacji.

Sama Java zaleca to podejście i jest używane w ich przykładach .

Prawdopodobnie nie przyniesie mi to wielu nowych przyjaciół, ale należy dodać, że ludzie w C # mają inne wytyczne: Instancje enum to „przypadek Pascala” (mieszane duże / małe litery). Patrz dyskusja stackoverflow i MSDN Typ wyliczenia Naming wytyczne .

Kiedy wymieniamy dane z systemem C #, kusi mnie, aby dokładnie skopiować ich wyliczenia, ignorując konwencję Java „stałe mają wielkie litery”. Myśląc o tym, nie widzę wielkiej wartości w ograniczeniu do wielkich liter w przypadkach wyliczania. Do niektórych celów .name () jest przydatnym skrótem do uzyskania czytelnej reprezentacji stałej wyliczeniowej, a nazwa mieszanej wielkości liter wyglądałaby ładniej.

Tak, śmiem kwestionować wartość konwencji nazewnictwa enum Java. Fakt, że „druga połowa świata programowania” rzeczywiście używa innego stylu, sprawia, że ​​uważam za uzasadnione wątpić w naszą własną religię.

Jak już wspomniano, wystąpienia enum powinny być pisane wielkimi literami zgodnie z dokumentami na stronie Oracle ( http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html ).

Jednak przeglądając samouczek JavaEE7 na stronie Oracle ( http://www.oracle.com/technetwork/java/javaee/downloads/index.html ) natknąłem się na samouczek „Księgarnia Duke'a” i na zajęciach ( tutorial\examples\case-studies\dukes-bookstore\src\main\java\javaeetutorial\dukesbookstore\components\AreaComponent.java), Znalazłem następującą definicję wyliczenia:

private enum PropertyKeys {
    alt, coords, shape, targetImage;
}

Zgodnie z konwencjami powinien on wyglądać następująco:

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

Wygląda więc na to, że nawet faceci z Oracle czasami handlują konwencją z łatwością.

W naszej bazie kodu; zazwyczaj deklarujemy wyliczenia w klasie, do której należą.

Na przykład w przypadku Owoców mielibyśmy klasę Owoców, a wewnątrz niej Enum zwane Owocami.

Odwoływanie się do niego w kodzie wygląda następująco: Fruit.Fruits.Apple, Fruit.Fruits.Pearitd.

Stałe podążają wzdłuż tej samej linii, gdzie albo zostają zdefiniowane w klasie, do której są istotne (więc coś podobnego Fruit.ORANGE_BUSHEL_SIZE); lub jeśli dotyczą całego systemu (tj. równoważnej „wartości zerowej” dla liczb całkowitych) w klasie o nazwie „ConstantManager” (lub równoważnej; podobnej ConstantManager.NULL_INT). (uwaga dodatkowa; wszystkie nasze stałe są wielkie)

Jak zawsze, twoje standardy kodowania prawdopodobnie różnią się od moich; więc YMMV.

Nadal są typami, więc zawsze używam tych samych konwencji nazewnictwa, których używam dla klas.

Zdecydowanie zmarszczyłbym brwi z powodu nadania nazwy „Class” lub „Enum”. Jeśli masz zarówno A FruitClassi FruitEnumA, coś innego jest nie tak i potrzebujesz bardziej opisowych nazw. Próbuję pomyśleć o rodzaju kodu, który prowadziłby do potrzebowania obu. Wydaje się, że powinna istnieć Fruitklasa podstawowa z podtypami zamiast wyliczenia. (Ale to tylko moje spekulacje, możesz mieć inną sytuację niż sobie wyobrażam.)

Najlepsze odniesienie, jakie mogę znaleźć dla nazw stałych, pochodzi z samouczka Zmienne :

Jeśli wybrana nazwa składa się tylko z jednego słowa, przeliteruj to słowo małymi literami. Jeśli składa się z więcej niż jednego słowa, wielką literę należy wpisać pierwszą literę każdego kolejnego słowa. Nazwy gearRatio i currentGear są doskonałymi przykładami tej konwencji. Jeśli twoja zmienna przechowuje stałą wartość, na przykład statyczną końcową liczbę całkowitą NUM_GEARS = 6, konwencja nieznacznie się zmienia, wielkie litery każdej litery i oddzielanie kolejnych słów znakiem podkreślenia. Umownie znak podkreślenia nie jest nigdy używany w innym miejscu.

Jeśli mogę dodać moje 0,02 $, wolę używać PascalCase jako wartości wyliczeniowych w C.

W C są one zasadniczo globalne, a PEER_CONNECTED staje się naprawdę męczący w przeciwieństwie do PeerConnected.

Powiew świeżego powietrza.

Dosłownie sprawia, że ​​oddycham łatwiej.

W Javie można używać nieprzetworzonych nazw wyliczeniowych, o ile importujesz je statycznie z innej klasy.

import static pkg.EnumClass.*;

Teraz możesz używać niekwalifikowanych nazw, które już zakwalifikowałeś w inny sposób.

Obecnie myślę o przeniesieniu kodu C na Javę i „rozdartym” między wyborem konwencji Java (która jest bardziej szczegółowa, dłuższa i bardziej brzydka) a moim stylem C.

PeerConnected stałby się PeerState.CONNECTED, z wyjątkiem instrukcji switch, gdzie jest CONNECTED.

Teraz jest wiele do powiedzenia na temat tej drugiej konwencji i wygląda ona ładnie, ale pewne „idiomatyczne frazy”, takie jak if (s == PeerAvailable)stają się podobne if (s == PeerState.AVAILABLE)i nostalgiczne, jest to dla mnie utrata znaczenia.

Wydaje mi się, że nadal wolę styl Java ze względu na przejrzystość, ale z trudem patrzę na krzykliwy kod.

Teraz zdaję sobie sprawę, że PascalCase jest już szeroko stosowany w Javie, ale bardzo mylące, tak naprawdę nie byłoby, tylko odrobinę nie na miejscu.

enum MyEnum {VALUE_1,VALUE_2}

jest (w przybliżeniu) jak powiedzenie

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

więc myślę, że wszystkie czapki są ściśle poprawne, ale nadal używam konwencji nazw klas, ponieważ nienawidzę wszystkich czapek gdziekolwiek