Devo riutilizzare le variabili?

Il tuo problema compare solo quando i tuoi metodi sono lunghi e svolgono più attività in una sequenza. Questo rende il codice più difficile da capire (e quindi mantenere) di per sé. Riutilizzare le variabili aggiunge un ulteriore elemento di rischio, rendendo il codice ancora più difficile da seguire e più incline agli errori.

La migliore pratica dell'IMO è quella di usare metodi abbastanza corti che facciano solo una cosa, eliminando l'intero problema.

Il riutilizzo variabile in un metodo è un segno strong che dovresti rifattarlo / dividerlo.

Quindi la mia risposta sarebbe che non dovresti riutilizzarli, perché se lo fai allora sarebbe molto più difficile rifattorizzarlo più tardi.

Dipende.

Alcune variabili potrebbero essere create esattamente allo scopo di contenere un determinato tipo di dati, che possono cambiare durante l'esecuzione di una funzione. I codici di ritorno vengono in mente qui, ad esempio:

void my_function() {
    HRESULT errorcode;
    errorcode = ::SomeWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
    errorcode = ::AnotherWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
}

Il nome della variabile rende molto chiaro ciò che questa variabile è destinata a memorizzare. Penso che altri casi come questo sono possibili, in cui una variabile è concettualmente un contenitore che è logicamente utilizzato da diverse istanze di cose molto simili durante il corso di una funzione.

In generale, tuttavia, questo dovrebbe essere fatto solo in circostanze in cui è assolutamente chiaro ai possibili lettori del codice. In nessun caso, eccetto forse l'ottimizzazione estrema senza riguardo per la leggibilità del codice, se una variabile può essere riutilizzata solo perché il tipo si adatta.

Tutto ciò deriva fondamentalmente da buone pratiche nella denominazione delle variabili. I nomi dovrebbero parlare da soli. Se è difficile mettere lo scopo esatto per tutti i riutilizzati in un nome breve, è meglio usare solo variabili distinte.

La più grande ragione per cui non riuso le variabili (specialmente nei test di unità) è perché introduce un percorso di codice non necessario, difficile da testare ed eseguire il debug. Un buon test unitario dovrebbe essere indipendente da altri test e quando si riutilizza la variabile di livello di classe (istanza) in un dispositivo di test unitario, è necessario assicurarsi di affermare il proprio stato prima di ogni test. Un buon test unitario isola anche i difetti quindi in teoria ogni test case (metodo) dovrebbe solo affermare 1 comportamento per il sistema sotto test. Se i tuoi metodi di test sono scritti in questo modo, raramente c'è bisogno o beneficio di riutilizzare una variabile di livello del metodo. Infine, nelle lingue che supportano le chiusure e l'elaborazione asincrona, è davvero difficile ragionare su cosa diavolo sta succedendo se si riutilizzano le variabili in un metodo.

Dovresti usare variabili diverse. Se sei preoccupato che il tuo collega sarà confuso, dai loro nomi che coprano chiaramente i loro ruoli.
Il riutilizzo delle variabili è una probabile fonte di confusione in futuro; meglio chiarirlo adesso.
In alcuni casi, è possibile riutilizzare lo stesso nome di variabile; per esempio i in un semplice ciclo di conteggio. In questi casi, dovresti assicurarti che le variabili siano nel loro ambito.

MODIFICA: le variabili di riutilizzo a volte sono un segno che il principio di singola responsabilità è stato violato. Controlla se la variabile riutilizzata viene utilizzata nello stesso ruolo. Se lo è, potrebbe non essere riutilizzato affatto (anche se potrebbe essere ancora preferibile avere due variabili diverse, per limitare l'ambito di dette variabili). Se viene utilizzato in ruoli diversi, hai una violazione SRP nelle tue mani.

C'è una situazione in cui potresti voler riutilizzare una variabile indipendentemente dall'ottimo consiglio dato da altre risposte: quando il tuo compilatore ha bisogno di aiuto.

In alcuni casi il compilatore potrebbe non essere abbastanza intelligente da comprendere che una determinata variabile allocata dal registro non viene più utilizzata dalla parte successiva del codice. Pertanto non riutilizzerà quel registro teoricamente libero per le variabili successive e il codice generato potrebbe essere non ottimale.

Si noti che non conosco nessun compilatore mainstream corrente che non riesca a cogliere correttamente questa situazione, quindi mai e poi mai lo farà a meno che non si sappia che il compilatore sta generando codice non ottimale. Se si sta compilando per sistemi embedded speciali con compilatori personalizzati, si potrebbe ancora incorrere in questo problema.

Direi NO.

Pensa a questo scenario: il tuo programma si è bloccato e hai bisogno di capire cosa è successo ispezionando un core dump ... puoi vedere la differenza? ; -)

No, non stai migliorando il codice che la macchina sta eseguendo (... il codice assembly). Lasciare riutilizzare la memoria che il compilatore usa per la variabile nel compilatore. Molto spesso sarà un registro, e il riutilizzo non ti ha comprato nulla. Concentrati a rendere il codice più facile da leggere.

Dipende. In un linguaggio dinamico, in cui il tipo risiede su valori anziché su variabili, allora se avessi un argomento ben chiamato a una funzione che, ad esempio, era una stringa. Una modifica dell'algoritmo significava che veniva sempre usata dopo essere stata interpretata come un numero intero, quindi, come prima bozza avrei potuto fare l'equivalente di

scrote = int (scrote)

Ma alla fine guarderei per cambiare il tipo inviato alla funzione e annotare la modifica nel tipo di parametro.

Per prima cosa, guarda il tuo ambiente di sviluppo. Se hai problemi di debug perché hai cinque variabili in ambiti diversi con nomi identici, e il debugger non ti mostra quale di queste variabili è quella che ti serve, allora non usare cinque variabili con lo stesso nome. Ci sono due modi per ottenere ciò: usa una variabile o usa cinque nomi diversi.

Il tuo debugger potrebbe anche rendere difficile il debug di una funzione con molte variabili. Se una funzione con 20 variabili è più difficile eseguire il debug di una con 16 variabili, è possibile prendere in considerazione la possibilità di sostituire 5 variabili con una. ("Potrebbe prendere in considerazione" non è lo stesso di "dovrebbe sempre").

È corretto avere una variabile usata in più posti purché la variabile abbia sempre lo stesso scopo. Ad esempio, se dieci chiamate di funzione restituiscono un codice di errore, che viene gestito immediatamente per ciascuna chiamata, utilizzare una variabile e non 10. Tuttavia, non utilizzare la stessa variabile per cose completamente diverse. Come usare "nome" per il nome di un cliente e 10 righe dopo usando la stessa variabile per il nome di una società, è male e ti metteresti nei guai. Peggio ancora, usando "customerName" per il nome di un cliente e 10 righe dopo usando la stessa variabile "customerName" per il nome di una società.

È importante sottolineare che nulla è una regola ferrea. Tutto ha vantaggi e svantaggi. Se le "migliori pratiche" suggeriscono una cosa, e hai ragione di dire che è una cattiva idea nella tua situazione specifica, allora non farlo.

Per prima cosa, guarda il tuo ambiente di sviluppo. Se hai problemi di debug perché hai cinque variabili in ambiti diversi con nomi identici, e il debugger non ti mostra quale di queste variabili è quella che ti serve, allora non usare cinque variabili con lo stesso nome. Ci sono due modi per ottenere ciò: usa una variabile o usa cinque nomi diversi.

Il tuo debugger potrebbe anche rendere difficile il debug di una funzione con molte variabili. Se una funzione con 20 variabili è più difficile eseguire il debug di una con 16 variabili, è possibile prendere in considerazione la possibilità di sostituire 5 variabili con una. ("Potrebbe prendere in considerazione" non è lo stesso di "dovrebbe sempre").

È corretto avere una variabile usata in più posti purché la variabile abbia sempre lo stesso scopo. Ad esempio, se dieci chiamate di funzione restituiscono un codice di errore, che viene gestito immediatamente per ogni chiamata, utilizzare una variabile e non 10. C'è un problema con questo: Di solito, il compilatore ti dirà quando usi una variabile non inizializzata. Ma qui, se leggi il codice di errore dopo la chiamata 6, ma la variabile non è stata effettivamente cambiata dopo la chiamata 5, otterrai dati inutili senza che il compilatore ti avverta. Perché la variabile è stata inizializzata, con dati che ora sono inutili.

È importante sottolineare che nulla è una regola ferrea. Tutto ha vantaggi e svantaggi. Se le "migliori pratiche" suggeriscono una cosa, e hai ragione di dire che è una cattiva idea nella tua situazione specifica, allora non farlo.

Utilizza le variabili globali quando è necessario mantenere uno stato o memorizzare le costanti. Riutilizzando le variabili si sta solo riutilizzando il nome che punta a una posizione nella memoria. I nomi descrittivi sulle inizializzazioni possono solo farti guadagnare la chiarezza (presupponendo Java e nessun primitivo OCD).

A meno che tu non stia eseguendo l'offuscamento del codice a mano o irritando altri sviluppatori.