Ad esempio, per mantenere una CPU attiva su Android, posso usare un codice come questo:

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();

ma penso che le variabili locali powerManagere wakeLockpossano essere eliminate:

((PowerManager)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
    .acquire();

scena simile appare nella vista di avviso di iOS, ad esempio: da

UIAlertView *alert = [[UIAlertView alloc]
    initWithTitle:@"my title"
    message:@"my message"
    delegate:nil
    cancelButtonTitle:@"ok"
    otherButtonTitles:nil];
[alert show];

-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex{
    [alertView release];
}

per:

[[[UIAlertView alloc]
    initWithTitle:@"my title"
    message:@"my message"
    delegate:nil
    cancelButtonTitle:@"ok"
    otherButtonTitles:nil] show];

-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex{
    [alertView release];
}

È buona norma eliminare una variabile locale se viene utilizzata una sola volta nell'ambito?

Il codice viene letto molto più spesso di quanto sia scritto, quindi dovresti avere pietà della povera anima che dovrà leggere il codice tra sei mesi (potresti essere tu) e cercare il codice più chiaro e più facile da capire. Secondo me, la prima forma, con variabili locali, è molto più comprensibile. Vedo tre azioni su tre righe, anziché tre azioni su una riga.

E se pensi di ottimizzare qualcosa eliminando le variabili locali, non lo sei. Un moderno compilatore inserirà powerManagerun registro ¹ , indipendentemente dal fatto che venga utilizzata o meno una variabile locale, per chiamare il newWakeLockmetodo. Lo stesso vale per wakeLock. Quindi in entrambi i casi si ottiene lo stesso codice compilato.

¹ Se tra la dichiarazione e l'uso della variabile locale fosse presente un sacco di codice, questo potrebbe andare nello stack, ma è un dettaglio minore.

Alcuni commenti altamente votati lo hanno affermato, ma nessuna delle risposte che ho visto lo ha fatto, quindi lo aggiungerò come risposta. Il tuo fattore principale nel decidere questo problema è:

Debuggability

Spesso, gli sviluppatori impiegano molto più tempo e sforzi nel debug rispetto alla scrittura di codice.

Con le variabili locali, puoi:

• Punto di interruzione sulla linea in cui è assegnato (con tutte le altre decorazioni del punto di interruzione, come il punto di interruzione condizionale, ecc ...)

• Ispeziona / guarda / stampa / cambia il valore della variabile locale

• Problemi di cattura dovuti a calchi.

• Tracce di stack leggibili (la riga XYZ ha un'operazione anziché 10)

Senza variabili locali, tutte le attività sopra descritte sono molto più difficili, estremamente difficili o assolutamente impossibili, a seconda del debugger.

Come tale, segui la famigerata massima (scrivi il codice in un modo come se lo sviluppatore successivo a mantenerlo dopo te stesso fosse un folle pazzo che sa dove vivi) e sbaglia dal lato della debuggabilità più semplice , nel senso che usa le variabili locali .

Solo se semplifica la comprensione del codice. Nei tuoi esempi, penso che sia più difficile da leggere.

L'eliminazione delle variabili nel codice compilato è un'operazione banale per qualsiasi compilatore rispettabile. È possibile ispezionare l'output manualmente per verificare.

La tua domanda "è una buona pratica eliminare una variabile locale se viene usata una sola volta nell'ambito?" sta testando criteri sbagliati. L'utilità di una variabile locale non dipende dal numero di volte in cui viene utilizzata, ma dal fatto che renda il codice più chiaro. L'etichettatura di valori intermedi con nomi significativi può migliorare la chiarezza in situazioni come quella che presenti poiché scompone il codice in blocchi più piccoli, più digeribili.

A mio avviso, il codice non modificato che hai presentato è più chiaro del tuo codice modificato e quindi dovrebbe essere lasciato invariato. In effetti, prenderei in considerazione l'estrazione di una variabile locale dal codice modificato per migliorare la chiarezza.

Non mi aspetto alcun impatto sulle prestazioni dalle variabili locali e, anche se ce n'è uno, è probabile che sia troppo piccolo per essere preso in considerazione, a meno che il codice non sia in un ciclo molto stretto in una parte critica della velocità del programma.

Può essere.

Personalmente esiterei ad eliminare le variabili locali se è coinvolto un typecast. Trovo la tua versione compatta meno leggibile poiché il numero di parentesi inizia ad avvicinarsi a un limite mentale che ho. Introduce anche un nuovo set di parentesi che non era necessario nella versione leggermente più dettagliata usando una variabile locale.

L'evidenziazione della sintassi fornita dall'editor di codice potrebbe mitigare tali preoccupazioni in una certa misura.

Ai miei occhi, questo è il miglior compromesso:

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc").acquire();

Mantenendo così una variabile locale e abbandonando l'altra. In C # userei la parola chiave var sulla prima riga poiché il typecast fornisce già le informazioni sul tipo.

Sebbene io accetti la validità delle risposte a favore delle variabili locali, interpreterò l'avvocato del diavolo e presenterò una visione contrarian.

Personalmente sono in qualche modo contrario all'utilizzo delle variabili locali puramente per ciò che equivale a scopi di documentazione, anche se quella stessa ragione indica che la pratica ha valore: le variabili locali effettivamente pseudo-documentano il codice.

Nel tuo caso, il problema principale è il rientro e non l'assenza di variabili. Puoi (e dovresti) formattare il codice come segue:

((PowerManager)getSystemService(POWER_SERVICE))
        .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"MyWakelockTag")
        .acquire();

Confrontalo con la versione con le variabili locali:

PowerManager powerManager=(PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"abc");
wakeLock.acquire();

Con le variabili locali: i nomi aggiungono alcune informazioni al lettore e i tipi sono chiaramente specificati, ma le chiamate ai metodi effettivi sono meno visibili e (secondo me) non leggono così chiaramente.

Senza usare le variabili locali: è più conciso e le chiamate al metodo sono più visibili, ma potresti chiedere maggiori informazioni su ciò che viene restituito. Alcuni IDE possono mostrartelo comunque.

Tre ulteriori commenti:

1. A mio avviso, l'aggiunta di codice che non ha alcun uso funzionale a volte può essere fonte di confusione in quanto il lettore deve rendersi conto che non ha effettivamente alcun uso funzionale ed è semplicemente lì per "documentazione". Ad esempio, se questo metodo fosse lungo 100 righe non sarebbe ovvio che le variabili locali (e quindi il risultato della chiamata al metodo) non sarebbero state richieste in un secondo momento a meno che non si leggesse l'intero metodo.

2. L'aggiunta delle variabili locali significa che è necessario specificare i loro tipi e questo introduce una dipendenza nel codice che altrimenti non ci sarebbe. Se il tipo restituito dei metodi è cambiato in modo banale (ad esempio, è stato rinominato) dovresti aggiornare il tuo codice, mentre senza le variabili locali non lo faresti.

3. Il debug potrebbe essere più semplice con le variabili locali se il debugger non mostra valori restituiti dai metodi. Ma la soluzione è quella di correggere le carenze nei debugger, non cambiare il codice.

C'è una tensione di motivazioni qui. L'introduzione di variabili temporanee può facilitare la lettura del codice. Ma possono anche prevenire e rendere più difficile la visualizzazione di altri possibili refactoring, come Estrai metodo e Sostituisci temp con query . Questi ultimi tipi di refactoring, se del caso, offrono spesso benefici molto maggiori rispetto alla variabile temp.

Sulle motivazioni di questi ultimi refactoring, Fowler scrive :

"Il problema con le temperature è che sono temporanee e locali. Poiché possono essere viste solo nel contesto del metodo in cui vengono utilizzate, le temperature tendono a incoraggiare metodi più lunghi, perché è l'unico modo per raggiungere la temperatura. sostituendo la temp con un metodo di query, qualsiasi metodo nella classe può ottenere le informazioni. Ciò aiuta molto a trovare un codice più pulito per la classe. "

Quindi sì, usa temps se rendono il codice più leggibile, specialmente se questa è una norma locale per te e il tuo team. Ma tieni presente che a volte puoi rendere più difficile individuare miglioramenti alternativi più grandi. Se riesci a sviluppare la tua capacità di percepire quando vale la pena andare senza tali temperature e sentirti più a tuo agio nel farlo, probabilmente è una buona cosa.

FWIW Ho personalmente evitato di leggere il libro "Refactoring" di Fowler per dieci anni perché immaginavo che non ci fosse molto da dire su argomenti relativamente semplici. Ho sbagliato completamente. Quando alla fine l'ho letto, ha cambiato le mie pratiche quotidiane di codifica, tanto per il meglio.

Bene, è una buona idea eliminare le variabili locali se è possibile rendere il codice più leggibile in tal modo. Quel lungo one-liner non è leggibile, ma segue uno stile OO piuttosto prolisso. Se potessi ridurlo a qualcosa del genere

acquireWakeLock(POWER_SERVICE, PARTIAL, "abc");

allora direi che probabilmente sarebbe una buona idea. Forse puoi introdurre metodi di aiuto per ridurlo a qualcosa di simile; se codice come questo appare più volte, potrebbe valere la pena.

Consideriamo qui la Legge di Demetra . Nell'articolo di Wikipedia su LoD si afferma quanto segue:

La Legge di Demetra per le funzioni richiede che un metodo m di un oggetto O possa invocare solo i metodi dei seguenti tipi di oggetti: [2]

1. O stesso
2. parametri di m
3. Qualsiasi oggetto creato / istanziato entro m
4. Oggetti componenti diretti di O.
5. Una variabile globale, accessibile da O, nell'ambito di m

Una delle conseguenze derivanti dal seguire questa Legge è che dovresti evitare di invocare metodi di oggetti restituiti da altri metodi in una lunga stringa tratteggiata insieme, come mostrato nel secondo esempio sopra:

((PowerManager)getSystemService(POWER_SERVICE)).newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"MyWakelockTag").acquire();

È davvero difficile capire cosa stia facendo. Per capirlo devi capire cosa fa ogni procedura, quindi decifrare quale funzione viene chiamata su quale oggetto. Il primo blocco di codice

PowerManager powerManager=(PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock=powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"abc");
wakeLock.acquire();

mostra chiaramente cosa stai cercando di fare: stai ottenendo un oggetto PowerManager, ottenendo un oggetto WakeLock da PowerManager, quindi acquisendo wakeLock. Quanto sopra segue la regola n. 3 di LoD: stai istanziando questi oggetti nel tuo codice e quindi puoi usarli per fare ciò di cui hai bisogno.

Forse un altro modo di pensare è di ricordare che quando si crea un software è necessario scrivere per chiarezza, non per brevità. Il 90% di tutto lo sviluppo del software è di manutenzione. Non scrivere mai un pezzo di codice che non saresti felice di mantenere.

Buona fortuna.

Una cosa da notare è che il codice viene letto frequentemente, a "profondità" diverse. Questo codice:

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();

è facile "scremare". Sono 3 affermazioni. Per prima cosa ci viene in mente un PowerManager. Quindi arriviamo a WakeLock. Poi abbiamo acquirela wakeLock. Posso vederlo davvero facilmente solo guardando l'inizio di ogni riga; le assegnazioni di variabili semplici sono davvero facili da riconoscere parzialmente come "Digitare varName = ..." e sfiorare mentalmente il "...". Allo stesso modo l'ultima affermazione non è ovviamente la forma del compito, ma coinvolge solo due nomi, quindi la "sostanza principale" è immediatamente evidente. Spesso è tutto ciò che avrei bisogno di sapere se stavo solo cercando di rispondere "cosa fa questo codice?" a un livello elevato.

Se sto inseguendo un bug sottile che penso sia qui, allora ovviamente dovrò andare su questo in modo molto più dettagliato e in realtà ricorderò i "...". Ma la struttura separata delle istruzioni mi aiuta ancora a fare quella frase alla volta (particolarmente utile se ho bisogno di approfondire l'implementazione delle cose chiamate in ogni dichiarazione; quando torno ho capito perfettamente "un'unità" e può quindi passare all'istruzione successiva).

((PowerManager)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
    .acquire();

Ora è tutta una frase. La struttura di livello superiore non è così facile da leggere; nella versione originale dell'OP, senza interruzioni di riga e rientri per comunicare visivamente qualsiasi struttura, avrei dovuto contare le parentesi per decodificarlo in una sequenza di 3 passaggi. Se alcune delle espressioni multiparte sono nidificate l'una nell'altra anziché disposte come una catena di chiamate di metodo, allora potrebbe comunque apparire simile a questo, quindi devo stare attento a fidarmi di ciò senza contare le parentesi. E se mi fido del rientro e guardo avanti fino all'ultima cosa come il punto presunto di tutto ciò, cosa .acquire()mi dice da solo?

A volte, però, può essere quello che vuoi. Se applico la trasformazione a metà strada e scrivo:

WakeLock wakeLock =
     ((PowerManeger)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakeLockTage");
wakeLock.acquire();

Ora questo comunica a una breve scrematura "prendi a WakeLock, allora acquire". Ancora più semplice della prima versione. È immediatamente ovvio che la cosa acquisita è a WakeLock. Se ottenere il PowerManagerè solo un sotto-dettaglio che è abbastanza insignificante fino al punto di questo codice, ma wakeLockè importante, allora potrebbe effettivamente aiutare a seppellire la PowerManagerroba quindi è naturale passarci sopra se stai solo cercando di ottenere rapidamente un idea di cosa fa questo codice. E non nominando, comunica che viene usato solo una volta, e talvolta lo è ciò che è importante (se il resto dell'ambito è molto lungo, dovrei leggere tutto questo per dire se è mai stato usato di nuovo; sebbene l'uso di sotto-ambiti espliciti possa essere un altro modo per affrontarlo, se la tua lingua li supporta).

Il che fa capire che tutto dipende dal contesto e da cosa vuoi comunicare. Come per la scrittura di prosa in linguaggio naturale, ci sono sempre molti modi per scrivere una determinata parte di codice che sono sostanzialmente equivalenti in termini di contenuto informativo. Come con la scrittura in prosa in linguaggio naturale, come si sceglie tra di loro dovrebbero generalmente non essere quello di applicare regole meccanicistiche come "eliminare ogni variabile locale che si verifica solo una volta". Piuttosto comescegli di scrivere il tuo codice enfatizzerà alcune cose e ne de-enfatizzerà altre. Dovresti sforzarti di fare queste scelte consapevolmente (inclusa la scelta di scrivere codice meno leggibile per motivi tecnici a volte), in base a ciò che vuoi davvero sottolineare. Pensa in particolare a ciò che servirà ai lettori che hanno solo bisogno di "capire il codice" del tuo codice (a vari livelli), dal momento che ciò accadrà molto più spesso di una lettura espressione per espressione molto ravvicinata.

Questo è persino un antipasto con il suo nome: Train Wreck . Sono già stati indicati diversi motivi per evitare la sostituzione:

• Più difficile da leggere
• Più difficile da eseguire il debug (sia per guardare le variabili e rilevare le posizioni delle eccezioni)
• Violazione della legge di Demetra (LoD)

Considera se questo metodo sa troppo dagli altri oggetti. Il concatenamento dei metodi è un'alternativa che potrebbe aiutarti a ridurre l'accoppiamento.

Ricorda inoltre che i riferimenti agli oggetti sono davvero economici.

La domanda dichiarata è "Dovremmo eliminare le variabili locali se possiamo"?

No, non dovresti eliminarlo solo perché puoi.

Dovresti seguire le linee guida per la codifica nel tuo negozio.

Per la maggior parte, le variabili locali rendono il codice più semplice da leggere ed eseguire il debug.

Mi piace quello che hai fatto PowerManager powerManager. Per me un minuscolo della classe significa che è solo un uso una volta.

Quando non dovresti, è se la variabile si terrà su risorse costose. Molte lingue hanno la sintassi per una variabile locale che deve essere ripulita / rilasciata. In C # sta usando.

using(SQLconnection conn = new SQLconnnection())
{
    using(SQLcommand cmd = SQLconnnection.CreateCommand())
    {
    }
}

Un aspetto importante non è stato menzionato nelle altre risposte: ogni volta che aggiungi una variabile, introduci uno stato mutabile. Questo di solito è una cosa negativa perché rende il codice più complesso e quindi più difficile da capire e testare. Naturalmente, minore è l'ambito della variabile, minore è il problema.

Quello che vuoi in realtà non è una variabile il cui valore può essere modificato ma una costante temporanea. Pertanto, considera di esprimerlo nel tuo codice se la tua lingua lo consente. In Java puoi usare finale in C ++ puoi usare const. Nella maggior parte dei linguaggi funzionali, questo è il comportamento predefinito.

È vero che le variabili locali sono il tipo meno dannoso di stato mutabile. Le variabili membro possono causare molti più problemi e le variabili statiche sono ancora peggio. Tuttavia trovo importante esprimere nel tuo codice nel modo più preciso possibile ciò che dovrebbe fare. E c'è un'enorme differenza tra una variabile che potrebbe essere modificata in seguito e un semplice nome per un risultato intermedio. Quindi, se la tua lingua ti consente di esprimere questa differenza, fallo e basta.