Konwencja nazewnictwa: Pola końcowe (nie statyczne)

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?

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ść.

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