Конвенція про іменування: Остаточні поля (не статичні)


23

Сьогодні у мене відбулася дискусія з колегою про найменування finalполів у класах Java.

У його finalполях опитування також слід вважати константами, оскільки їх значення не зміняться після створення екземпляра.

Це призведе до наступного договору іменування finalполів:

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

    private final String BAR_BATZ;

    ...
}

На мою думку, лише static finalполя слід вважати константами, тоді як поля, які є лише, finalповинні дотримуватися звичайної конвенції про іменування camelCase.

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

    private final String barBatz;

    ...
}

Зараз я трохи невпевнено, оскільки він набагато досвідченіший програміст, ніж я, і зазвичай я згоден з його думкою і вважаю його дуже хорошим розробником.

Будь-який внесок на це?


Ваші приклади не константи; ви не призначили їм жодних значень під час компіляції. Ерго, вони не дотримуються умов іменування констант.
Роберт Харві

@RobertHarvey Спасибі, ви праві. ...Мав символізувати будь-який можливий конструктор , який задає finalполе, але це, очевидно , НЕ представляється можливим для static finalполя.
Саша Вовк

1
@Zeeker вас можуть зацікавити static { }блоки, які можна використовувати для встановлення статичних полів у класі один раз при завантаженні класу. Пов'язані Робота зі статичним конструктором на Java .

@RobertHarvey Я знайомий з ними. Але все-таки спасибі.
Саша Вовк

1
Я б сказав, що оскільки змінна належить до екземпляра, вона буде відрізнятися від примірника до інстанції, тому вона не застосовується як константа. Я б використав верблюдний чохол.
Флоріан Ф

Відповіді:


20

Sun (і зараз Oracle) підтримує документ під назвою " Конвенції коду для мови програмування Java" . Останнє оновлення до цього було в 99-му році, але суть керівництва за стилем живе далі.

Розділ 9 охоплює умови іменування.

Для типу ідентифікатора "константи":

Імена змінних, оголошених константами класу та констант ANSI, повинні бути всіма великими літерами зі словами, розділеними підкресленнями ("_"). (Для спрощення налагодження слід уникати констант ANSI.)

Наведені приклади:

static final int MIN_WIDTH = 4;

static final int MAX_WIDTH = 999;

static final int GET_THE_CPU = 1;

У нещодавньому документі - його там прослизнуло. З змінних (Підручники Java> Вивчення мови Java> Основи мови :

Якщо вибране ім’я складається лише з одного слова, напишіть це слово всіма малими літерами. Якщо воно складається з декількох слів, з великої літери напишіть кожне наступне слово. Назви gearRatioта currentGearосновні приклади цієї конвенції. Якщо ваша змінна зберігає постійне значення, наприклад static final int NUM_GEARS = 6, конвенція незначно змінюється, використовуючи великі літери і відокремлюючи наступні слова символом підкреслення. За умовою, символ підкреслення ніколи не використовується в іншому місці.

Багато статичних аналізаторів для Java прагнуть цього застосувати. Наприклад, контрольний стиль :

Перевіряє, чи відповідають постійні імена формату, визначеному властивістю формату. Константа - це статичне і кінцеве поле або поле інтерфейсу / анотації, за винятком serialVersionUIDі serialPersistentFields. Формат є регулярним виразом і за замовчуванням ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$.


Це дійсно зводиться до конвенцій спільноти про написання коду ... і в ідеалі зберігати його таким же.

Наведені вище приклади наводяться як static finalті, які, ймовірно, походять із конвенцій C для #define- які, як і C, замінюються в коді під час компіляції, а не під час виконання.

Питання, яке тоді слід задати, - це "чи поводиться це як константа? Чи поводиться він як поле запису один раз?" - і відповідно дотримуючись конвенцій. Лакмусовим тестом для такого питання було б "Якби ви серіалізували об'єкт, ви включили б остаточне поле?" Якщо відповідь полягає в тому, що це константа, тоді ставитесь до цього як до такого (і не серіалізуйте). З іншого боку, якщо це частина стану об'єкта, яку потрібно було б серіалізувати, то це не константа.

Незалежно від випадку, важливо дотримуватися стилю коду, наскільки це правильно чи неправильно. Гірші проблеми випливають із непослідовної конвенції в рамках проекту, ніж просто те, що ображає око. Розгляньте можливість отримання деяких інструментів статичного аналізу та налаштуйте їх на підтримку узгодженості.



@RobertHarvey Я міг би уявити деякі ситуації, коли поле екземпляра поводиться як константа. Наприклад, Фабрика, що заповнює щось, що інакше було б постійною в об'єкті ... хоча вони потрапляють до досить надуманих прикладів, які болять мені в голові, думаючи про те, навіщо це робити.

Дякую за цю детальну відповідь. Лакмусовий тест про серіалізацію об’єкта зробив для мене угоду.
Саша Вовк

Нещодавно колега підкреслив свою думку, сказавши, що колись редактори не дуже добре підкреслювали статичні / статичні фінали тощо, тому ця умова про іменування була важливою. У наші дні ІДЕ є досить гарними, тому ми можемо зробити приємніші назви для них, наприклад: MinWidthзамість MIN_WIDTH. Інше питання: а як статичні кінцеві реєстратори? Ви їх називаєте LOG/ LOGGERабо log/ logger. Особисто logвиглядає краще з кодом, але коли невідповідність прийнятна, якщо вона взагалі?
ndtreviv

5

BAR_BATZне є постійною в цьому прикладі. Конструктори Fooможуть встановлювати його на різні значення на рівні об'єкта. Наприклад

public class Foo {
    private final String BAR_BATZ;

    Foo() {
       BAR_BATZ = "ascending";
    } 

    Foo(String barBatz) {
       BAR_BATZ = barBatz;
    }
}
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.