Perché si dovrebbero contrassegnare variabili locali e parametri del metodo come “finali” in Java?

In Java, è ansible qualificare variabili locali e parametri del metodo con la parola chiave finale.

public static void foo(final int x) { final String qwerty = "bar"; } 

Così facendo non si riesce a riassegnare x e qwerty nel corpo del metodo.

Questa pratica spinge il tuo codice nella direzione di immutabilità che è generalmente considerata un vantaggio. Ma tende anche a ingombrare il codice con “finale” che appare ovunque. Qual è la tua opinione sulla parola chiave finale per le variabili locali e i parametri del metodo in Java?

Dovresti provare a farlo, ogni volta che è appropriato. Oltre a servire per avvisarti quando “accidentalmente” provi a modificare un valore, fornisce informazioni al compilatore che possono portare ad una migliore ottimizzazione del file di class. Questo è uno dei punti del libro, “Hardcore Java” di Robert Simmons, Jr. In effetti, il libro passa tutto il suo secondo capitolo sull’uso della finale per promuovere le ottimizzazioni e prevenire gli errori logici. Gli strumenti di analisi statica come PMD e la built-in SA di Eclipse contrassegnano questo tipo di casi per questo motivo.

La mia opinione personale è che è una perdita di tempo. Credo che la confusione visiva e la verbosità aggiunta non ne valga la pena.

Non sono mai stato in una situazione in cui sono stato riassegnato (ricorda, questo non rende immutabili gli oggetti, significa solo che non puoi riassegnare un altro riferimento a una variabile) una variabile in errore.

Ma, naturalmente, sono tutte preferenze personali 😉

La definizione di un parametro finale garantisce che il valore utilizzato in qualsiasi posizione nel metodo faccia riferimento al valore passato. Altrimenti devi analizzare mentalmente tutto il codice sopra una determinata posizione per sapere quale valore ha il parametro in quel punto.

Quindi, non usare finale rende il tuo codice meno leggibile e manutenibile, tutto da solo 🙂

Le variabili locali finali dipendono dall’intenzione e sono meno importanti dal mio punto di vista. Dipende da cosa succede.

Nel caso delle variabili locali, tendo ad evitare questo. Causa disordine visivo, e in genere non è necessario – una funzione dovrebbe essere abbastanza breve o concentrarsi su un singolo impatto per consentire di vedere rapidamente che si sta modificando qualcosa che non dovrebbe essere.

Nel caso di numeri magici, li inserirò comunque come campo privato costante piuttosto che nel codice.

Uso solo final in situazioni in cui è necessario (ad esempio, passare valori a classi anonime).

A causa della (a volte) confusa natura del comportamento di ” passaggio per riferimento ” di Java, sono assolutamente d’accordo con la finalizzazione dei parametri var.

La finalizzazione delle var locali sembra un po ‘eccessivo.

Si fallo.

Si tratta di leggibilità. È più facile ragionare sui possibili stati del programma quando si sa che le variabili vengono assegnate una sola volta.

Un’alternativa decente è quella di triggersre l’avviso IDE quando viene assegnato un parametro o quando una variabile (diversa da una variabile di loop) viene assegnata più di una volta.

la finale ha tre buone ragioni:

  • le variabili di istanza impostate dal costruttore diventano immutabili
  • i metodi che non devono essere sovrascritti diventano definitivi, lo usano con veri motivi, non di default
  • le variabili locali oi parametri da utilizzare in classi anonime all’interno di un metodo devono essere definitive

Come i metodi, le variabili locali e i parametri non devono essere dichiarati definitivi. Come altri hanno già detto, questo fa in modo che il codice diventi meno leggibile con un minimo sforzo per l’ottimizzazione del performace del compilatore, questo non è un vero motivo per la maggior parte dei frammenti di codice.

Anche se crea un po ‘di confusione, vale la pena mettere la final . Ides, ad es. Eclipse, può automaticamente mettere il final se lo si configura per farlo.

Rendere le variabili locali e i parametri del metodo final è essenziale se si desidera passare quei parametri in classi anonime, ad esempio si istanzia un thread anonimo e si desidera accedere a tali parametri nel corpo del metodo run ().

A parte questo, non sono sicuro che i benefici delle prestazioni possano migliorare le prestazioni attraverso l’ottimizzazione del compilatore. Spetta all’implementazione specifica del compilatore se vuole ottimizzarlo a tutti …

Sarà bene sapere di tutte le statistiche delle prestazioni dall’uso final

Perché vorresti? Hai scritto il metodo, quindi chiunque lo modificasse poteva sempre rimuovere la parola chiave finale da qwerty e riassegnarla. Per quanto riguarda la firma del metodo, lo stesso ragionamento, anche se non sono sicuro di cosa farebbe alle sottoclassi della tua class … potrebbero ereditare il parametro finale e anche se hanno la precedenza sul metodo, non riuscire a de-finalizzare x. Provalo e scopri se potrebbe funzionare.

L’unico vero vantaggio, quindi, è se si rende il parametro immutabile e si trasferisce ai bambini. Altrimenti, stai solo ingombrando il tuo codice senza una buona ragione. Se non costringerà nessuno a seguire le tue regole, è meglio lasciare un buon commento perché non dovresti cambiare quel parametro o variabile invece di dare se il modificatore finale.

modificare

In risposta a un commento, aggiungerò che se si riscontrano problemi di prestazioni, rendere definitive le variabili locali e i parametri può consentire al compilatore di ottimizzare meglio il codice. Tuttavia, dal punto di vista dell’immutabilità del tuo codice, sostengo la mia dichiarazione originale.

Lascio che Eclipse lo faccia per me quando vengono utilizzati in una class anonima, che sta aumentando a causa del mio utilizzo dell’API di Google Collection.

Lo facciamo qui per le variabili locali se pensiamo che non saranno riassegnati o non dovrebbero essere riassegnati.

I parametri non sono definitivi poiché abbiamo un Checkstyle-Check che controlla i parametri di riassegnazione. Ovviamente nessuno vorrebbe mai riassegnare una variabile parametro.