Konwencje kodowania - Nazwy enumów


289

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.?


2
Zrób z niego Wiki Wiki. Ponieważ nie ma jednej akceptowalnej odpowiedzi, która w innym przypadku zostałaby zamknięta.
Alexander Pogrebnyak

13
@Alexander Pogrebnyak Nie, jest odpowiedź.
Tom Hawtin - tackline

Odpowiedzi:


473

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 .


22
Zacząłem nazywać moje wyliczenia w ten sposób, ale dla czytelności korzystam teraz z Fruit.Apple zamiast Fruit.APPLE.

38
@Walter Dlaczego tworzenie instancji enum wyglądałoby tak, jakby była klasą zwiększającą czytelność?
DJClayworth,

17
Technicznie instancje enum klasami. Dlatego mogą mieć metody.
Ted Hopp,

87
Nie, instancja enum jest instancją. Wyliczenie jest klasą.
DJClayworth,

30
Pomysł wzorca nazewnictwa, który sprawia, że ​​wpisuję Fruit.APPLE.chew () naprawdę mnie wkurza. Ponadto, choć byłaby to bardzo zła praktyka, APPLE nie musi być stały (niezmienny). Przy promocji wyliczeń do pełnych klas java nie jestem pewien, czy stosowanie konwencji opracowanych dla czegoś, co nawet nie istniało w c (Przedmioty, nie wyliczenia) zawsze ma sens
Bill K

76

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ę.


7
TIL, że tylko programiści Java lub C # są prawdziwymi programistami i że ich liczba jest równa. #sarkazm
Mindwin

14
C # jest poza tym świetnym językiem, ale jest to po prostu głupie. W języku C # wszystko jest w zasadzie pascal, co w zasadzie jest tym samym, co brak konwencji nazewnictwa; nic nie zyskujesz patrząc na imię. Nie wiadomo, czy to klasa, metoda, właściwość itp.
Bassinator

3
Ponadto wartość logiczna jest praktycznie wyliczeniem, instancje są prawdziwe i fałszywe małymi literami. Tak, wszystkie czapki są brzydkie.
Florian F,

@FlorianF, nie należy mylić typu boolean typu podstawowego z klasą Boolean ( docs.oracle.com/javase/7/docs/api/java/lang/Boolean.html ). klasa korzysta z konwencji wielkimi literami
IvoC

24

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ą.


13

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.


5
Chcę dodać, że wydaje się, że fabryki obiektów są obecnie nazywane przy użyciu liczby mnogiej, na przykład Listsi Maps. Moim zdaniem jest to dobra konwencja i w pełni popieram jej szersze zastosowanie.
Esko

Tak, są one podobne do moich osobistych standardów kodowania, ale różnią się od moich standardów kodowania w miejscu pracy. Nie mamy wielu standardów pracy, więc staram się znaleźć dobry dokument, który można by wykorzystać jako odniesienie.

8
Fruit.Fruits.Applejest dla mnie zbyt gadatliwy, dosłownie łamiąc zasadę SUCHEGO :-) Wolałbym np Fruit.Type.APPLE.
Péter Török

2
Nie podoba mi się to podejście. Jak to się nazywa, jabłko albo jest owocem, albo przynajmniej jest mylące, ponieważ nie jest jasne, czy jabłko nie jest owocem. Podoba mi się przykład Petera. Przynajmniej wtedy samokokumentuje, że APPLE jest rodzajem owocu. Chociaż cały ten przykład owoców pachnie trochę zgniłym ...
Mark Peters

1
Też mi się nie podoba. Jeśli klasa „Owoc” reprezentuje owoc (i powinna), to co może oznaczać „Owoce”? Jeśli Fruit (klasa) naprawdę jest klasą do obsługi Fruit, należy ją zmienić na „FruitHandler” lub „FruitManager”.
DJClayworth

7

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.


Odwołanie do stałych nazewnictwa znajduje się na stronie oracle.com/technetwork/java/javase/documentation/…
Christoffer Hammarström

1

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.


0
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

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.