Convenzione di denominazione: campi finali (non statici)

Question

Convenzione di denominazione: campi finali (non statici)

#1 da (17 voti)
#2 da (4 voti)

18

Oggi ho avuto una discussione con un collega sulla denominazione dei campi final nelle classi Java.

Nel suo opionion final i campi dovrebbero essere considerati costanti in quanto i loro valori non cambieranno dopo la creazione dell'istanza.

Questo porterebbe alla seguente convenzione di denominazione per i campi final :

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

    private final String BAR_BATZ;

    ...
}

A mio parere, solo i campi di static final dovrebbero essere considerati costanti mentre i campi che sono solo final dovrebbero seguire la consueta convenzione di denominazione di camelCase.

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

    private final String barBatz;

    ...
}

Ora sono un po 'incerto dal momento che è un programmatore di gran lunga più esperto di me e di solito sono d'accordo con le sue opinioni e lo considero un ottimo sviluppatore.

Qualche input su questo?

java naming final

posta Zeeker 04.08.2014 - 16:12

fonte

2 risposte

4

BAR_BATZ non è una costante in questo esempio. I costruttori di Foo possono impostarlo su valori diversi a livello di oggetto. Ad esempio

public class Foo {
    private final String BAR_BATZ;

    Foo() {
       BAR_BATZ = "ascending";
    } 

    Foo(String barBatz) {
       BAR_BATZ = barBatz;
    }
}

risposta data 17.08.2016 - 19:15

fonte

Leggi altre domande sui tag java naming final

Che aspetto ha la tua documentazione tecnica? [duplicare] Git submodule vs Git clone

score 17 · Accepted Answer

Sun (e ora Oracle) ha mantenuto un documento intitolato Convenzioni sui codici per il linguaggio di programmazione Java . L'ultimo aggiornamento a questo era nel '99, ma l'essenza della linea guida sullo stile è ancora viva.

Capitolo 9 riguarda le convenzioni di denominazione.

Per un tipo di identificatore di 'costanti':

The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_"). (ANSI constants should be avoided, for ease of debugging.)

Gli esempi forniti:

static final int MIN_WIDTH = 4;

static final int MAX_WIDTH = 999;

static final int GET_THE_CPU = 1;

In un documento più recente - è scivolato lì dentro. Da Variabili (Java Tutorials > Apprendimento della lingua Java > Nozioni di base sulla lingua :

If the name you choose consists of only one word, spell that word in all lowercase letters. If it consists of more than one word, capitalize the first letter of each subsequent word. The names gearRatio and currentGear are prime examples of this convention. If your variable stores a constant value, such as static final int NUM_GEARS = 6, the convention changes slightly, capitalizing every letter and separating subsequent words with the underscore character. By convention, the underscore character is never used elsewhere.

Molti analizzatori statici per Java cercano di far rispettare questo. Ad esempio checkstyle applica:

Checks that constant names conform to a format specified by the format property. A constant is a static and final field or an interface/annotation field, except serialVersionUID and serialPersistentFields. The format is a regular expression and defaults to ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$.

Questo in realtà si riduce alle convenzioni della comunità che scrivono il codice ... e idealmente lo mantengono lo stesso.

Gli esempi sopra sono dati come static final quelli che sono probabilmente derivati dalle convenzioni C per #define - che come C, sono sostituiti nel codice durante la compilazione piuttosto che al runtime.

La domanda che dovrebbe essere posta è: "si sta comportando come una costante? o si sta comportando come un campo di scrittura una sola volta?" - e quindi seguendo le convenzioni di conseguenza. La cartina di tornasole per una tale domanda sarebbe "Se dovessi serializzare l'oggetto, includeresti il campo finale?" Se la risposta è che è una costante, trattala come tale (e non serializzarla). D'altra parte, se è parte dello stato dell'oggetto che dovrebbe essere serializzato, allora non è una costante.

In ogni caso, è importante attenersi allo stile del codice, tuttavia è giusto o sbagliato. I problemi peggiori derivano da convenzioni inconsistenti all'interno di un progetto piuttosto che qualcosa che offende l'occhio. Prendi in considerazione la possibilità di ottenere alcuni strumenti di analisi statica e configurarli per mantenere la coerenza.