Variabili multiple con lo stesso nome all'interno di un metodo

Mi piacciono le variabili nominate correttamente ma in alcuni casi è molto difficile da fare.Variabili multiple con lo stesso nome all'interno di un metodo

Quindi, se il mio oggetto implementa IDisposable poi posso usare:

using (var whatever = new Whatever()) { //... }

Ma è caso raro, così ho trovato un altro modo di gestire la cosa - blocco anonimo (non so come si chiama correttamente):

//... 
{ 
    var whatever = new Whatever(); 
    //... 
} 
//... 
if (condition) 
{ 
    var whatever = new Whatever(); 
}

È un buon approccio? Ci sono insidie o convinzione diffusa che riduce la leggibilità del codice?

fonte

2013-06-04 Vladimirs

Anche se ho letto la domanda, perché non il nome della variabile, dopo quello che sta andando ad essere utilizzato per, piuttosto che ciò che è stato dichiarato dal ? –

Perché non puoi semplicemente sovrascrivere "qualunque cosa?" 'var whatever = new(); ... whatever = new(); ... ' – SimpleVar

Normalmente dividerei il metodo in metodi diversi invece ... almeno in molti casi. –

Fondamentalmente, se il compilatore non si lamenta e il tuo codice è leggibile e facile da capire, non c'è niente di sbagliato in questo.

Ad esempio:

foreach (var foo in foos) 
{ 
    var task = new FooTask(foo); 
    task.Run(); 
} 
foreach (var bar in bars) 
{ 
    var task = new BarTask(bar); 
    task.Run(); 
}

Questo è in realtà (a mio parere) leggermente più facile da leggere rispetto

foreach (var foo in foos) 
{ 
    var task1 = new FooTask(foo); 
    task1.Run(); 
} 
foreach (var bar in bars) 
{ 
    var task2 = new BarTask(bar); 
    task2.Run(); 
}

fonte

2013-06-04 16:13:05

'var task = foo? new FooTask(): new BarTask(); task.Run(); 'mi sembra più leggibile, in questo caso. Ma non è possibile se entrambi non implementano alcune interfacce 'IRunnableTask', o qualcosa di simile. – SimpleVar

@YoryeNathan Sì, sono d'accordo, stavo solo cercando di trovare un caso adatto alla domanda di OP. Ho aggiornato la mia risposta con i blocchi 'foreach' che illustrano il punto un po 'meglio. –

Non uso mai nomi di variabili enumerate perché credo che sia anche una cattiva pratica nella denominazione della conversione. Quindi in tal caso sarebbe meglio dare nomi che possano scoprire meglio lo scopo di utilizzo variabile. Ma nel mio caso le variabili sono diventate strane e troppo lunghe – Vladimirs

Ho appena provato il codice perché normalmente, con VSCodeAnalysis e R # e StyleCop respirazione mi sarei aspettato un sacco di avvertimenti al collo. Ma no. Stanno tutti zitti. Quindi non sembra essere contro nessuna linea guida di codifica di Microsoft.

Tuttavia: Se è necessario creare blocchi anonimi superflui solo per evitare errori del compilatore dovuti a nomi di variabili, non è più facile e semplice. Fondamentalmente, ti stai nascondendo dal compilatore e nascondere non risolverà mai problemi. Dal mio punto di vista, sarebbe un codice molto migliore se scegliessi un nome preciso per ciascuna variabile (nominandolo per il tipo non è esattamente eccezionale in ogni caso) e rimuovi il blocco anonimo.

Seguendo il Principio del KISS: "Keep it simple, stupid".

fonte

2013-06-04 16:24:36 nvoigt

Sarei cauto con questo approccio; può impedire la leggibilità e la debugabilità. In passato ho avuto situazioni in cui avevo due punti di interruzione che osservavano due variabili diverse quando pensavo di osservarne una.

Le regole che C# impone per garantire che i metodi non utilizzino i nomi in modo incoerente sono complicati. Se siete interessati a saperne di più su di loro, vedi:

http://blogs.msdn.com/b/ericlippert/archive/tags/simple+names/

fonte

2013-06-04 17:05:20

Variabili multiple con lo stesso nome all'interno di un metodo

risposta

Problemi correlati