È buona pratica dichiarare le variabili "finali" laddove possibile?

Question

Eventuali duplicati:
When should one use final?

tendo a dichiarare tutte le variabili final se non strettamente necessario. Considero ciò una buona pratica perché consente al compilatore di verificare che l'identificatore sia usato come mi aspetto (ad esempio non è mutato). D'altra parte ingombra il codice e forse questo non è "il modo Java".

Mi chiedo se esiste una best practice generalmente accettata per quanto riguarda l'uso non obbligatorio delle variabili finali e se ci sono altri compromessi o aspetti di questa discussione che dovrebbero essere messi a conoscenza.

Answer 1

Alcuni buoni strumenti di analisi, come PMD, consigliano di inserire sempre final se necessario. Quindi la convenzione in quegli strumenti dice che è una buona pratica

Ma penso che così tanti gettoni finali nel codice possano renderlo meno umano.

Answer 2

Lo considero una buona pratica, più per i programmatori di manutenzione (incluso me!) Che per il compilatore. È più semplice pensare a un metodo se non devo preoccuparmi di quali variabili potrebbero cambiare all'interno di esso.

Answer 3

Assicura sicuramente un codice migliore, facile vedere quali variabili verranno modificate.

Informa inoltre il compilatore che non sta per cambiare, il che può comportare una migliore ottimizzazione.

Lungo il lato consente all'ID di ricevere notifiche sulla compilazione in caso di errore.

Answer 4

È praticamente riassunto i pro ei contro ...

posso solo aggiungere un altro con:

il lettore del codice non ha bisogno di ragionare a tutti circa il valore di una variabile finale (ad eccezione dei rari casi di codice errato).

Quindi, sì, è una buona pratica.

E il disordine non è poi così male, dopo ci si abitua (come unix :-P). Inoltre, gli IDE tipici lo fanno automaticamente per ya ...

Answer 5

Il "modo Java" è intrinsecamente, intrinsecamente un clutaggio.

Dico che è una buona pratica, ma non una che seguo.

I test generalmente assicurano che sto facendo quello che intendo, ed è anche cluttery per la mia estetica.

Answer 6

Sì, è una buona idea, perché mostra chiaramente quali campi devono essere forniti nella costruzione dell'oggetto.

Non sono affatto d'accordo sul fatto che crei "codice ingombrante"; è un aspetto buono e potente della lingua.

Come principio di progettazione, è possibile creare classi immutable (tutti i campi finali) se è possibile, poiché possono essere pubblicati in modo sicuro (ovvero spostati liberamente senza timore che siano danneggiati). Sebbene si noti che i campi stessi devono essere anche oggetti immutabili.

Answer 7

Direi di sì, non tanto per l'ottimizzazione del compilatore, quanto piuttosto per la leggibilità.

Ma personalmente non lo uso. Java è piuttosto prolisso da solo, e se seguissimo tutto considerato "buona pratica", il codice non sarebbe più utilizzabile da tutti gli standard. È una questione di preferenza, però.

Answer 8

applico ordinariamente final alle variabili locali nel mio codice e inoltre trovo codice lettura molto più facile dopo il primo aver segnato tutti effictively finali variabili con la parola chiave final. Considero questo un miglioramento in buona fede del codice, e lo commetto subito dopo.

Per quanto riguarda l'ingombro del codice, quando applicato a variabili locali non lo trovo dannoso — infatti mi fa individuare tutte le dichiarazioni più facilmente a causa della colorazione della sintassi.

devo ammettere, però, che io faccio trovarlo insopportabile cluttery quando final viene utilizzato su parametri, blocchi catch Enhanced-per cicli e tutti gli altri luoghi, ad eccezione variabili locali in senso stretto. Questo è piuttosto spiacevole perché una riassegnazione in questi casi è ancora più confusa e in realtà dovrebbero essere stati definitivi per impostazione predefinita.