Сегодня у меня была дискуссия с коллегой по поводу именования 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;
...
}
Теперь я немного неуверен, поскольку он гораздо более опытный программист, чем я, и я обычно согласен с его мнением и считаю его очень хорошим разработчиком.
Любой вклад в это?
...
должен был символизировать любой возможный конструктор, который устанавливаетfinal
поле, но это явно невозможно дляstatic final
поля.static { }
блоки, которые можно использовать для установки статических полей в классе один раз при загрузке класса. Связанные Работа со статическим конструктором в Java .Ответы:
Sun (а теперь и Oracle) поддерживает документ под названием « Соглашения по коду для языка программирования Java» . Последнее обновление этого было в '99, но суть линии руководства по стилю живет.
Глава 9 охватывает соглашения об именах.
Для типа идентификатора «константы»:
Приведенные примеры:
В более свежем документе - он проскользнул туда. Из переменных (Учебные руководства Java> Изучение языка Java> Основы языка :
Многие статические анализаторы для Java стремятся обеспечить это. Например, checkstyle обеспечивает:
Это действительно сводится к условностям сообщества, пишущего код ... и в идеале сохраняющему его прежним.
Приведенные выше примеры даны как примеры
static final
, которые, вероятно, получены из соглашений C, для#define
которых, как и C, заменяются в коде во время компиляции, а не во время выполнения.Вопрос, который следует задать: «Это ведет себя как константа? Или оно ведет себя как поле однократной записи?» - и затем, следуя конвенциям, соответственно. Лакмусовая бумажка для такого вопроса будет такой: «Если бы вы сериализовали объект, включили бы вы последнее поле?» Если ответ таков: это константа, тогда относитесь к ней как к таковой (и не сериализуйте ее). С другой стороны, если это часть состояния объекта, которую необходимо сериализовать, то это не константа.
В любом случае важно придерживаться стиля кода, каким бы правильным или неправильным он ни был. Хуже проблемы возникают из-за непоследовательных соглашений в проекте, а не просто из-за того, что оскорбляет глаз. Подумайте о приобретении некоторых инструментов статического анализа и настройте их для обеспечения согласованности.
источник
MinWidth
вместоMIN_WIDTH
. Другой вопрос: как насчет статических финальных регистраторов? Вы называете ихLOG
/LOGGER
илиlog
/logger
. Личноlog
выглядит лучше в соответствии с кодом, но когда допустимо несоответствие, если вообще?BAR_BATZ
не является константой в этом примере. КонструкторыFoo
могут устанавливать различные значения на уровне объекта. Напримеристочник