Perché dichiarare le variabili vicino al punto in cui sono utilizzate?

Questa è una regola di stile tra molte e non è necessariamente la regola più importante di tutte le possibili regole che potresti prendere in considerazione. Il tuo esempio, dal momento che include un int, non è super-convincente, ma potresti certamente avere un oggetto costoso da costruire all'interno di quel ciclo, e forse un buon argomento per costruire l'oggetto al di fuori del ciclo. Tuttavia, questo non lo rende un buon argomento contro questa regola dato che, in primo luogo, ci sono tonnellate di altri posti che potrebbe applicare che non implicano la costruzione di oggetti costosi in un ciclo, e in secondo luogo, un buon ottimizzatore (e tu hai taggato C #, quindi hai un buon ottimizzatore) puoi sollevare l'inizializzazione dal ciclo.

La vera ragione di questa regola è anche la ragione per cui non vedi perché è una regola. Le persone erano solite scrivere funzioni che erano centinaia, anche migliaia di righe e che usavano scriverle in editor di testo semplice (si pensi al Blocco note) senza il tipo di supporto fornito da Visual Studio. In quell'ambiente, dichiarare una variabile a centinaia di linee lontano da dove è stato usato significava che la persona che leggeva

if (flag) limit += factor;

non aveva molti indizi su cosa fossero bandiera, limite e fattore. Le convenzioni di denominazione come la notazione ungherese sono state adottate per aiutare con questo, e quindi c'erano regole come dichiarare le cose vicino a dove sono usate. Ovviamente, in questi giorni, si tratta di refactoring e le funzioni sono in genere meno lunghe di una pagina, rendendo difficile ottenere molta distanza tra dove vengono dichiarate le cose e dove vengono utilizzate. Stai operando in un intervallo compreso tra 0-20 e quibbling che forse 7 è ok in questa particolare istanza, mentre il tizio che ha fatto la regola avrebbe dovuto LOVED ottenere 7 linee e stava cercando di parlare con qualcuno a partire da 700. E su in cima a ciò, in Visual Studio, puoi scorrere il mouse su qualsiasi cosa e vedere il suo tipo, è una variabile membro e così via. Ciò significa che è necessario vedere la riga che la dichiara ridotta.

È ancora una regola abbastanza buona, una che in realtà è piuttosto difficile da rompere in questi giorni e una che nessuno ha mai sostenuto come motivo per scrivere codice lento. Sii sensibile, soprattutto.

La definizione della variabile all'interno del loop rende visibile la visibilità solo su quel loop. Questo ha almeno 3 vantaggi per il lettore:

1. La definizione delle variabili e qualsiasi commento correlato sono facili da trovare
2. Il lettore sa che questa variabile non viene mai usata altrove dove (no dipendenza da prevedere)
3. Quando il codice è scritto o modificato, non c'è alcuna possibilità che tu possa usare lo stesso nome di variabile al di fuori del ciclo per fare riferimento a quella variabile altrimenti, potresti avere un errore.

Per quanto riguarda il bit di efficienza, il compilatore è in grado di generare la definizione al di fuori del ciclo nel codice ottimizzato generato. La variabile non verrà creata ogni iterazione del ciclo.

Le persone dicono il più vicino possibile al loro utilizzo , Non stanno dicendo che dovresti doverlo fare sempre, perché sono alcuni casi in cui le variabili che riguardano almeno lo scope causeranno un sovraccarico. I motivi principali di questa affermazione sono la leggibilità e dare alle variabili il più piccolo ambito possibile.

Anche se aiuta con la leggibilità, la leggibilità non è la considerazione principale in questo caso, e gli IDE moderni non eliminano la necessità di questa regola.

La preoccupazione principale sono le variabili non inizializzate. Se dichiari una variabile troppo lontana dalla sua inizializzazione, ti apre tutti i tipi di potenziali problemi. Potresti trovarti a lavorare accidentalmente con quello che è successo nella RAM precedente, o il risultato di un calcolo più alto nella funzione, o un'inizializzazione fittizia (come 0) che qualcuno ha inserito solo per impedire al compilatore di lamentarsi. Le persone inseriranno il codice tra la tua dichiarazione e il tuo utilizzo senza essere a conoscenza delle tue precondizioni implicite per quella variabile. Nei casi peggiori, quell'utilizzo funzionerà nei test ma fallirà nel campo.

Dichiarare le proprie variabili in un ambito il più piccolo possibile e inizializzarle su un valore adeguato proprio al momento della dichiarazione eviterà un gran numero di problemi di manutenzione. Il fatto che costringa a migliorare la leggibilità è solo un bell'effetto collaterale.

Non è un "must". È solo un'opinione, ho modo di fare qualcosa. Ad esempio, mi piace dichiarare tutti i vars nelle prime righe del metodo, così posso commentare cosa farò con quelle vars (ovviamente a meno che non siano contatori). Altre persone, come hai sentito, amano collocarle il più vicino possibile al loro utilizzo (come nel secondo esempio che hai scritto). Ad ogni modo, il primo esempio che fornisci è sicuramente un "errore" (nel senso che causerà un sovraccarico come capisci).

Devi semplicemente scegliere la tua strada e seguirla.

I tuoi due esempi sono codice funzionalmente diverso, non sono intercambiabili. (I tuoi esempi spogliati lasciano una distinzione senza differenze, ma in un codice non banale fa la differenza). La regola del tuo sito è sempre subordinata a considerazioni sull'ambito dell'ambito, come indicato da "... il più possibile".