Konwencja nazewnictwa: Pola końcowe (nie statyczne)

23

Dzisiaj rozmawiałem ze współpracownikiem na temat nazewnictwa finalpól w klasach Java.

W jego opionionach finalpola należy również traktować jako stałe, ponieważ ich wartości nie zmienią się po utworzeniu instancji.

Doprowadziłoby to do następującej konwencji nazewnictwa dla finalpól:

public class Foo {
    private static final String BLA_BLA = "bla";

    private final String BAR_BATZ;

    ...
}

Moim zdaniem tylko static finalpola powinny być uważane za stałe, podczas gdy pola, które są tylko, finalpowinny być zgodne ze zwykłą konwencją nazewnictwa camelCase.

public class Foo {
    private static final String BLA = "bla";

    private final String barBatz;

    ...
}

Teraz jestem trochę niepewny, ponieważ jest on o wiele bardziej doświadczonym programistą niż ja i zwykle zgadzam się z jego opiniami i uważam go za bardzo dobrego programistę.

Wszelkie uwagi na ten temat?

Wilk Sascha
źródło
Twoje przykłady nie są stałe; nie przypisałeś im żadnych wartości w czasie kompilacji. Ergo, nie przestrzegają konwencji nazewnictwa dla stałych.
Robert Harvey
@RobertHarvey Dzięki, masz rację. ...Miało symbolizować ewentualne konstruktora, który wyznacza finalpole, ale nie jest to oczywiście możliwe dla static finalpola.
Sascha Wolf,
1
@ Zeeker możesz być zainteresowany static { }blokami, które mogą być użyte do ustawienia pól statycznych w klasie, gdy klasa zostanie załadowana. Powiązane Praca z konstruktorem statycznym w Javie .
@RobertHarvey Znam je. Ale i tak dzięki.
Sascha Wolf,
1
Powiedziałbym, że ponieważ zmienna należy do instancji, będzie różna w zależności od instancji, więc nie będzie stosowana jako stała. Chciałbym użyć etui na wielbłądy.
Florian F

Odpowiedzi:

20

Firma Sun (a teraz Oracle) utrzymała dokument zatytułowany Konwencje kodu dla języka programowania Java . Ostatnia aktualizacja tego była w roku 99, ale istota linii przewodnika po stylach trwa nadal.

Rozdział 9 obejmuje konwencje nazewnictwa.

W przypadku typu identyfikatora „stałych”:

Nazwy zmiennych zadeklarowanych stałych klas i stałych ANSI powinny być pisane wielkimi literami ze słowami oddzielonymi znakami podkreślenia („_”). (Należy unikać stałych ANSI, aby ułatwić debugowanie).

Podane przykłady:

static final int MIN_WIDTH = 4;

static final int MAX_WIDTH = 999;

static final int GET_THE_CPU = 1;

W nowszym dokumencie - wślizgnął się tam. Z zmiennych (samouczki Java> Nauka języka Java> Podstawy języka :

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 gearRatioi currentGeargłówne przykłady tej konwencji. Jeśli zmienna przechowuje stałą wartość, na przykład static final int NUM_GEARS = 6konwencja nieznacznie się zmienia, wielkie litery każdej litery i oddzielane kolejnymi słowami znakiem podkreślenia. Umownie znak podkreślenia nie jest nigdy używany w innym miejscu.

Wiele statycznych analizatorów Java próbuje to wymusić. Na przykład styl sprawdzania wymusza:

Sprawdza, czy stałe nazwy są zgodne z formatem określonym przez właściwość format. Stała jest polem statycznym i końcowym lub polem interfejsu / opisu, z wyjątkiem serialVersionUIDi serialPersistentFields. Format jest wyrażeniem regularnym i domyślnie jest to ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$.


To naprawdę sprowadza się do konwencji społeczności piszących kod ... i idealnie zachowujących go bez zmian.

Powyższe przykłady podano jako static finalte, które prawdopodobnie pochodzą z konwencji C dla #define- które podobnie jak C, są zastępowane w kodzie podczas kompilacji, a nie w czasie wykonywania.

Pytanie, które należy następnie zadać, brzmi: „Czy to zachowuje się jak stała? Czy zachowuje się jak pole jednokrotnego zapisu?” - a następnie zgodnie z konwencjami. Test lakmusowy na takie pytanie brzmiałby: „Gdyby szeregować obiekt, czy uwzględniałby ostatnie pole?” Jeśli odpowiedź jest taka, że ​​jest stała, traktuj ją jako taką (i nie serializuj). Z drugiej strony, jeśli jest to część stanu obiektu, który wymagałby serializacji, to nie jest stała.

Niezależnie od przypadku ważne jest, aby zachować styl kodu, niezależnie od tego, czy jest on poprawny, czy zły. Gorsze problemy powstają w wyniku niespójnych konwencji w ramach projektu, a nie tylko czegoś, co obraża wzrok. Zastanów się nad uzyskaniem niektórych narzędzi do analizy statycznej i skonfiguruj je, aby zachować spójność.


źródło
@RobertHarvey Mogę sobie wyobrazić niektóre sytuacje, w których pole instancji zachowuje się jak stała. Fabryka, na przykład, wypełniająca coś, co w innym przypadku byłoby stałą w obiekcie ... chociaż przechodzą do raczej wymyślnych przykładów, które ranią moją głowę, myśląc o tym, dlaczego to zrobić.
Dziękuję za tę szczegółową odpowiedź. Test lakmusowy dotyczący serializacji obiektu zawarł u mnie umowę.
Sascha Wolf
Kolega niedawno stwierdził, że pewnego razu redaktorzy nie byli bardzo dobrzy w podkreślaniu statycznych / statycznych finałów itp., Więc ta konwencja nazewnictwa była ważna. Obecnie IDE są całkiem dobre, więc możemy stworzyć dla nich ładniejsze nazwy, np. MinWidthZamiast MIN_WIDTH. Kolejne pytanie brzmi: co ze statycznymi rejestratorami końcowymi? Dzwonisz do nich LOG/ LOGGERlub log/ logger. Osobiście logwygląda lepiej zgodnie z kodem, ale kiedy niespójność jest akceptowalna, jeśli w ogóle?
ndtreviv
5

BAR_BATZnie jest stałą w tym przykładzie. Konstruktory Foomogą ustawić różne wartości na poziomie obiektu. Na przykład

public class Foo {
    private final String BAR_BATZ;

    Foo() {
       BAR_BATZ = "ascending";
    } 

    Foo(String barBatz) {
       BAR_BATZ = barBatz;
    }
}
Kirby
źródło