A Sun (e agora Oracle) manteve um documento intitulado Convenções de Código para a Linguagem de Programação Java . A última atualização foi em 99, mas a essência da linha de guia de estilo continua viva.
O capítulo 9 aborda convenções de nomenclatura.
Para um tipo de identificador de 'constantes':
Os nomes das variáveis declaradas constantes de classe e de ANSI devem estar em maiúsculas com palavras separadas por sublinhados ("_"). (As constantes ANSI devem ser evitadas, para facilitar a depuração.)
Os exemplos dados:
static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;
Em um documento mais recente - ele entrou lá. Das variáveis (Os tutoriais de Java> Aprendendo a linguagem Java> Noções básicas de linguagem :
Se o nome escolhido consistir em apenas uma palavra, soletre essa palavra em todas as letras minúsculas. Se consistir em mais de uma palavra, coloque em maiúscula a primeira letra de cada palavra subsequente. Os nomes gearRatio
e currentGear
são exemplos principais desta convenção. Se sua variável armazena um valor constante, como, por exemplo static final int NUM_GEARS = 6
, a convenção muda um pouco, capitalizando cada letra e separando as palavras subsequentes com o caractere sublinhado. Por convenção, o caractere sublinhado nunca é usado em outro lugar.
Muitos analisadores estáticos para Java procuram aplicar isso. Por exemplo, o estilo de verificação impõe:
Verifica se os nomes constantes estão em conformidade com um formato especificado pela propriedade format. Uma constante é um campo estático e final ou um campo de interface / anotação, exceto serialVersionUID
e serialPersistentFields
. O formato é uma expressão regular e o padrão é ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$
.
Isso realmente se resume às convenções da comunidade escrevendo o código ... e, idealmente, mantendo o mesmo.
Os exemplos acima são dados como static final
aqueles que provavelmente são derivados das convenções C para #define
- que, como C, são substituídos no código durante a compilação e não no tempo de execução.
A pergunta que então deve ser feita é "isso está se comportando como uma constante? Ou está se comportando como um campo de gravação única?" - e depois seguindo as convenções em conformidade. O teste decisivo para essa pergunta seria "Se você fosse serializar o objeto, incluiria o campo final?" Se a resposta for uma constante, trate-a como tal (e não a serialize). Por outro lado, se for parte do estado do objeto que precisaria ser serializado, não será uma constante.
Seja qual for o caso, é importante manter o estilo do código, por mais certo ou errado que seja. Problemas piores surgem de convenções inconsistentes em um projeto do que apenas algo que ofende os olhos. Considere obter algumas ferramentas de análise estática e configurá-las para manter a consistência.