Utilizzo della parola chiave var in C#
https://stackoverflow.com/questions/41479
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Dopo aver discusso con i colleghi in merito all'uso della parola chiave "var" in C# 3, mi chiedevo quali fossero le opinioni delle persone sugli usi appropriati dell'inferenza del tipo tramite var?
Ad esempio, ho usato piuttosto pigramente var in circostanze discutibili, ad esempio: -
foreach(var item in someList) { // ... } // Type of 'item' not clear.
var something = someObject.SomeProperty; // Type of 'something' not clear.
var something = someMethod(); // Type of 'something' not clear.
Usi più legittimi di var sono i seguenti: -
var l = new List<string>(); // Obvious what l will be.
var s = new SomeClass(); // Obvious what s will be.
È interessante notare che LINQ sembra essere un po' un'area grigia, ad esempio: -
var results = from r in dataContext.SomeTable
select r; // Not *entirely clear* what results will be here.
È chiaro quali saranno i risultati in quanto sarà un tipo che implementa IEnumerable, tuttavia non è del tutto ovvio allo stesso modo in cui lo è una var che dichiara un nuovo oggetto.
È ancora peggio quando si tratta di LINQ to object, ad esempio: -
var results = from item in someList
where item != 3
select item;
Questo non è migliore dell'equivalente foreach(var item in someList) { // ...} equivalente.
C'è una reale preoccupazione riguardo all'indipendenza dai tipi qui: ad esempio, se dovessimo inserire i risultati di quella query in un metodo sovraccaricato che accettasse IEnumerable<int> e IEnumerable<double>, il chiamante potrebbe inavvertitamente passare il tipo sbagliato.
var fa mantenere una tipizzazione forte, ma la domanda è in realtà se sia pericoloso che il tipo non sia immediatamente evidente nella definizione, qualcosa che viene amplificato quando i sovraccarichi indicano che gli errori del compilatore potrebbero non essere emessi quando si passa involontariamente il tipo sbagliato a un metodo.
Soluzione
penso ancora var può rendere il codice più leggibile in alcuni casi.Se ho una classe Customer con una proprietà Orders e voglio assegnarla a una variabile, farò semplicemente questo:
var orders = cust.Orders;
Non mi interessa se Customer.Orders lo è IEnumerable<Order>, ObservableCollection<Order> O BindingList<Order> - tutto quello che voglio è mantenere quell'elenco in memoria per ripeterlo o ottenerne il conteggio o qualcosa del genere in seguito.
Confronta la dichiarazione di cui sopra con:
ObservableCollection<Order> orders = cust.Orders;
Per me, il nome del tipo è solo rumore.E se torno indietro e decido di cambiare la tipologia del cliente. Gli ordini successivi (ad esempio da ObservableCollection<Order> A IList<Order>) allora devo cambiare anche quella dichiarazione, cosa che non avrei dovuto fare se avessi usato var in primo luogo.
Altri suggerimenti
Io uso var ampiamente.Ci sono state critiche sul fatto che ciò diminuisca la leggibilità del codice, ma nessun argomento a sostegno di tale affermazione.
Certo, ciò può significare che non è chiaro con quale tipo abbiamo a che fare.E allora?Questo è in realtà lo scopo di una progettazione disaccoppiata.Quando hai a che fare con le interfacce, sei enfatico non interessato al tipo di una variabile. var va molto oltre, è vero, ma penso che l'argomento rimanga lo stesso dal punto di vista della leggibilità:Il programmatore in realtà non dovrebbe essere interessato al tipo di variabile ma piuttosto a cosa sia una variabile fa.Questo è il motivo per cui Microsoft chiama anche l’inferenza del tipo “digitazione duck”.
Allora, cosa fa una variabile quando la dichiaro using var?Facile, fa tutto ciò che IntelliSense mi dice di fare.Qualsiasi ragionamento su C# che ignori l'IDE non è realistico.In pratica ogni codice C# è programmato in un IDE che supporta IntelliSense.
Se sto usando a var variabile dichiarata e mi confondo sullo scopo della variabile, c'è qualcosa di fondamentalmente sbagliato nel mio codice. var non è la causa, rende solo visibili i sintomi.Non incolpare il messaggero.
Ora, il team C# ha rilasciato una linea guida di codifica che lo afferma var Dovrebbe soltanto essere utilizzato per acquisire il risultato di un'istruzione LINQ che crea un tipo anonimo (perché in questo caso non abbiamo una reale alternativa a var).Beh, al diavolo.Finché il team C# non mi fornisce una valida argomentazione a favore di questa linea guida, la ignorerò perché, secondo la mia opinione professionale e personale, è pura sciocchezza.(Scusa;Non ho alcun collegamento alla linea guida in questione.)
In realtà ce ne sono alcuni (superficialmente) buone spiegazioni sul motivo per cui non dovresti usarlo var ma continuo a credere che siano in gran parte sbagliati.Prendiamo l’esempio della “ricercabilità”:l'autore lo sostiene var rende difficile cercare i luoghi in cui MyType si usa.Giusto.Lo stesso vale per le interfacce.In realtà, perché dovrei sapere dove viene utilizzata la classe?Potrei essere più interessato a dove viene istanziato e questo sarà comunque ricercabile perché da qualche parte è necessario invocare il suo costruttore (anche se ciò avviene indirettamente, il nome del tipo deve essere menzionato da qualche parte).
Var, secondo me, in C# è a buona cosatm.Qualsiasi variabile così tipizzata è ancora fortemente tipizzata, ma ottiene il suo tipo dal lato destro dell'assegnazione dove è definita.Poiché le informazioni sul tipo sono disponibili sul lato destro, nella maggior parte dei casi non è necessario ed eccessivamente prolisso doverle inserire anche sul lato sinistro.Penso che questo aumenti significativamente la leggibilità senza diminuire la sicurezza del tipo.
Dal mio punto di vista, l'utilizzo di buone convenzioni di denominazione per variabili e metodi è più importante dal punto di vista della leggibilità rispetto alle informazioni sul tipo esplicito.Se ho bisogno delle informazioni sul tipo, posso sempre passare il mouse sopra la variabile (in VS) e ottenerle.In generale, tuttavia, al lettore non dovrebbero essere necessarie informazioni esplicite sul tipo.Per lo sviluppatore, in VS ottieni comunque Intellisense, indipendentemente da come viene dichiarata la variabile.Detto questo, potrebbero esserci ancora casi in cui ha senso dichiarare esplicitamente il tipo: forse hai un metodo che restituisce un List<T>, ma vuoi trattarlo come un file IEnumerable<T> nel tuo metodoPer garantire l'utilizzo dell'interfaccia, dichiarare la variabile del tipo di interfaccia può renderlo esplicito.O forse vuoi dichiarare una variabile senza un valore iniziale, perché ottiene immediatamente un valore in base ad alcune condizioni.In tal caso è necessario il tipo.Se le informazioni sul tipo sono utili o necessarie, vai avanti e usale.Ritengo, tuttavia, che in genere non sia necessario e nella maggior parte dei casi il codice è più facile da leggere senza di esso.
Nessuno di questi è assolutamente vero; var può avere effetti sia positivi che negativi sulla leggibilità.Secondo me, var dovrebbe essere utilizzato quando è vera una delle seguenti condizioni:
- Il tipo è anonimo (beh, non hai alcuna scelta qui, poiché it dovere essere var in questo caso)
- Il tipo è ovvio in base all'espressione assegnata (ad es.
var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())
var non ha alcun impatto sulle prestazioni, poiché è zucchero sintattico;il compilatore deduce il tipo e lo definisce una volta compilato in IL;non c'è niente In realtà dinamico al riguardo.
Da Eric Lippert, ingegnere progettista software senior del team C#:
Perché era il var parola chiave introdotta?
Ci sono due ragioni, uno che esiste oggi, uno che sorgerà in 3.0.
Il primo motivo è che questo codice è incredibilmente brutto a causa di tutta la ridondanza:
Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();E questo è un semplice esempio: ho scritto peggio.Ogni volta che sei costretto a digitare esattamente la stessa cosa due volte, questa è una ridondanza che possiamo rimuovere.Molto più bello da scrivere
var mylists = new Dictionary<string,List<int>>();E lascia che il compilatore capisca quale si basa il tipo sull'assegnazione.
In secondo luogo, C# 3.0 introduce tipi anonimi.Poiché i tipi anonimi per definizione non hanno nomi, tu Bisogno Essere in grado di dedurre il tipo di variabile dall'espressione di inizializzazione se il suo tipo è anonimo.
Sottolineo il mio.L'intero articolo, C# 3.0 è ancora tipizzato staticamente, onesto!, e il conseguente serie sono piuttosto buoni.
Questo è ciò var è per.Altri usi probabilmente non funzioneranno così bene.Qualsiasi confronto con JScript, VBScript o tipizzazione dinamica è una totale sciocchezza.Nota ancora, var È necessario per far sì che alcune altre funzionalità funzionino in .NET.
Penso che l'uso di var dovrebbe essere abbinato a nomi di variabili scelti saggiamente.
Non ho problemi a utilizzare var in un'istruzione foreach, a condizione che non sia così:
foreach (var c in list) { ... }
Se fosse più così:
foreach (var customer in list) { ... }
...quindi qualcuno che legge il codice avrebbe molte più probabilità di capire cos'è la "lista".Se hai il controllo sul nome della variabile di lista stessa, è ancora meglio.
Lo stesso può valere per altre situazioni.Questo è abbastanza inutile:
var x = SaveFoo(foo);
...ma questo ha senso:
var saveSucceeded = SaveFoo(foo);
Ognuno per conto suo, immagino.Mi sono ritrovato a fare questo, il che è semplicemente folle:
var f = (float)3;
Ho bisogno di una sorta di programma var in 12 passaggi.Mi chiamo Matt e (ab)uso var.
Abbiamo adottato l'etica "Codice per le persone, non per le macchine", basato sul presupposto che si trascorre molto più tempo in modalità di manutenzione che in un nuovo sviluppo.
Per me, questo esclude l'argomento secondo cui il compilatore "sa" di che tipo è la variabile: certo, non puoi scrivere codice non valido la prima volta perché il compilatore impedisce la compilazione del codice, ma quando lo sviluppatore successivo legge il codice entro 6 mesi devono essere in grado di dedurre cosa sta facendo la variabile in modo corretto o errato e identificare rapidamente la causa dei problemi.
Così,
var something = SomeMethod();
è vietato dai nostri standard di codifica, ma quanto segue è incoraggiato nel nostro team perché aumenta la leggibilità:
var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
DoWork( item );
}
Non è male, è più una questione stilistica, che tende ad essere soggettiva.Può aggiungere incoerenze, quando usi var e quando no.
Un altro caso preoccupante, nella chiamata seguente non puoi dirlo semplicemente guardando il codice da cui viene restituito il tipo CallMe:
var variable = CallMe();
Questa è la mia lamentela principale contro var.
Utilizzo var quando dichiaro delegati anonimi nei metodi, in qualche modo var sembra più pulito che se lo usassi Func.Considera questo codice:
var callback = new Func<IntPtr, bool>(delegate(IntPtr hWnd) {
...
});
MODIFICARE:Aggiornato l'ultimo esempio di codice in base all'input di Julian
Il Var non è affatto una variante.La variabile è ancora fortemente tipizzata, è solo che non premi i tasti per ottenerla in quel modo.Puoi passarci sopra con il mouse in Visual Studio per vedere il tipo.Se stai leggendo codice stampato, è possibile che tu debba pensarci un po' per capire quale sia il tipo.Ma c'è solo una riga che lo dichiara e molte righe che lo utilizzano, quindi dare alle cose nomi decenti è ancora il modo migliore per rendere il codice più facile da seguire.
L'uso di Intellisense è pigro?È meno digitabile del nome intero.Oppure ci sono cose che richiedono meno lavoro ma che non meritano critiche?Penso che ce ne siano, e var è uno di questi.
Il momento più probabile in cui ne avrai bisogno è per i tipi anonimi (dove è richiesto al 100%);ma evita anche la ripetizione di casi banali e l'IMO rende la linea più chiara.Non ho bisogno di vedere il tipo due volte per una semplice inizializzazione.
Per esempio:
Dictionary<string, List<SomeComplexType<int>>> data = new Dictionary<string, List<SomeComplexType<int>>>();
(per favore non modificare l'hscroll sopra - dimostra il punto!!!)
contro:
var data = new Dictionary<string, List<SomeComplexType<int>>>();
Ci sono, tuttavia, occasioni in cui ciò è fuorviante e può potenzialmente causare bug.Fare attenzione all'utilizzo var se la variabile originale e il tipo inizializzato non erano identici.Per esempio:
static void DoSomething(IFoo foo) {Console.WriteLine("working happily") }
static void DoSomething(Foo foo) {Console.WriteLine("formatting hard disk...");}
// this working code...
IFoo oldCode = new Foo();
DoSomething(oldCode);
// ...is **very** different to this code
var newCode = new Foo();
DoSomething(newCode);
Un caso specifico in cui var è difficile:revisioni del codice offline, soprattutto quelle effettuate su carta.
Non puoi fare affidamento sul passaggio del mouse per questo.
Non vedo quale sia il grosso problema..
var something = someMethod(); // Type of 'something' not clear <-- not to the compiler!
Hai ancora l'intellisense completo su "qualcosa" e per ogni caso ambiguo hai i tuoi test unitari, giusto?( Fai?)
Non è varchar, non è debole e certamente non è una digitazione dinamica o debole.Sta fermando la follia in questo modo:
List<somethinglongtypename> v = new List<somethinglongtypename>();
e ridurre il disordine mentale totale a:
var v = new List<somethinglongtypename>();
Bello, non così bello come:
v = List<somethinglongtypename>();
Ma allora ecco cosa Boh è per.
Se qualcuno sta usando il var parola chiave perché non vogliono "capire il tipo", questo è sicuramente il motivo sbagliato.IL var La parola chiave non crea una variabile con un tipo dinamico, il compilatore deve comunque conoscere il tipo.Poiché la variabile ha sempre un tipo specifico, se possibile il tipo dovrebbe essere evidente anche nel codice.
Buoni motivi per utilizzare il var le parole chiave sono ad esempio:
- Dove è necessario, ad es.per dichiarare un riferimento per un tipo anonimo.
- Dove rende il codice più leggibile, ad es.rimozione delle dichiarazioni ripetitive.
Scrivere il tipo di dati spesso rende il codice più facile da seguire.Mostra quali tipi di dati stai utilizzando, in modo che tu non debba capire il tipo di dati cercando prima di capire cosa fa il codice.
Data la potenza di Intellisense ora, non sono sicuro che var sia più difficile da leggere rispetto all'avere variabili membro in una classe o variabili locali in un metodo definite al di fuori dell'area visibile dello schermo.
Se hai una riga di codice come
IDictionary<BigClassName, SomeOtherBigClassName> nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();
È molto più facile o più difficile da leggere rispetto a:
var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();
Penso che la cosa fondamentale con VAR sia usarlo solo dove appropriato, ad es.quando si fanno cose in Linq che facilita (e probabilmente in altri casi).
Se hai avuto un tipo per qualcosa in allora dovresti usarlo - non farlo è semplice pigrizia (al contrario della pigrizia creativa che generalmente deve essere incoraggiata - i bravi programmatori spesso lavorano molto duramente per essere pigri e potrebbero essere considerati la fonte di tutto innanzitutto).
Un divieto generale è tanto grave quanto abusare del costrutto in primo luogo, ma è necessario che esista uno standard di codifica sensato.
L'altra cosa da ricordare è che non è una var di tipo VB in quanto non può cambiare tipo: it È una variabile fortemente tipizzata è solo che il tipo viene dedotto (motivo per cui ci sono persone che sostengono che non è irragionevole usarla, diciamo, in un foreach ma non sarei d'accordo per ragioni sia di leggibilità che di manutenibilità).
Sospetto che questo funzionerà e funzionerà (-:
Murph
Sicuro, int è facile, ma quando il tipo della variabile è IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var rende le cose molto più semplici.
Rubato dal post su questo problema su CodingHorror:
Sfortunatamente, tu e tutti gli altri avete praticamente sbagliato.Anche se sono d'accordo con te sul fatto che la ridondanza non è una buona cosa, il modo migliore per risolvere questo problema sarebbe stato fare qualcosa del genere:
MioOggetto m = nuovo();
Oppure se stai passando parametri:
Persona p = new("Nome", "Cognome);
Dove nella creazione di un nuovo oggetto, il compilatore deduce il tipo dal lato sinistro e non da quello destro.Questo ha altri vantaggi rispetto a "var", in quanto potrebbe essere utilizzato anche nelle dichiarazioni di campo (ci sono anche altre aree in cui potrebbe essere utile, ma non ne parlerò qui).
Alla fine, semplicemente non si intendeva ridurre la ridondanza.Non fraintendermi, "var" è MOLTO importante in C# per tipi/proiezioni anonime, ma l'uso qui è semplicemente VIA (e lo dico da molto, molto tempo) poiché offuschi il tipo che viene usato.Doverlo digitare due volte è troppo spesso, ma dichiararlo zero volte è troppo poco.
Nicholas Paldino .NET/C# MVP il 20 giugno 2008 08:00
Immagino che se la tua preoccupazione principale è dover digitare meno, allora non c'è alcun argomento che ti impedirà di usarlo.
Se solo lo farai mai sii la persona che guarda il tuo codice, quindi a chi importa?Altrimenti, in un caso come questo:
var people = Managers.People
va bene, ma in un caso come questo:
var fc = Factory.Run();
cortocircuita qualsiasi deduzione di tipo immediato che il mio cervello potrebbe iniziare a formare dall'inglese del codice.
Altrimenti, usa semplicemente il tuo miglior giudizio e la "cortesia" di programmazione nei confronti degli altri che potrebbero dover lavorare sul tuo progetto.
Utilizzando var invece del tipo esplicito rende i refactoring molto più semplici (quindi devo contraddire i poster precedenti che intendevano che non faceva alcuna differenza o che era puramente "zucchero sintattico").
Puoi modificare il tipo restituito dei tuoi metodi senza modificare ogni file in cui viene chiamato questo metodo.Immaginare
...
List<MyClass> SomeMethod() { ... }
...
che è usato come
...
IList<MyClass> list = obj.SomeMethod();
foreach (MyClass c in list)
System.Console.WriteLine(c.ToString());
...
Se volessi eseguire il refactoring SomeMethod() per restituire un IEnumerable<MySecondClass>, dovresti modificare la dichiarazione della variabile (anche all'interno del file foreach) in ogni luogo in cui hai utilizzato il metodo.
Se scrivi
...
var list = obj.SomeMethod();
foreach (var element in list)
System.Console.WriteLine(element.ToString());
...
invece, non è necessario modificarlo.
@aku:Un esempio sono le revisioni del codice.Un altro esempio sono gli scenari di refactoring.
Fondamentalmente non voglio andare a caccia di caratteri con il mouse.Potrebbe non essere disponibile.
È una questione di gusti.Tutto questo agitarsi per il tipo di una variabile scompare quando ti abitui ai linguaggi tipizzati dinamicamente.Questo è, Se inizi mai a piacerti (non sono sicuro che tutti possano, ma a me sì).
C# var è piuttosto interessante in questo sembra come la digitazione dinamica, ma in realtà lo è statico digitazione: il compilatore impone l'utilizzo corretto.
Il tipo della tua variabile non è poi così importante (questo è stato detto prima).Dovrebbe essere relativamente chiaro dal contesto (le sue interazioni con altre variabili e metodi) e dal suo nome: non aspettarti customerList contenere un int...
Sto ancora aspettando di vedere cosa ne pensa il mio capo di questa questione: ho ricevuto un "vai avanti" generale per utilizzare eventuali nuovi costrutti nella 3.5, ma cosa faremo per la manutenzione?
Nel tuo confronto tra IEnumerable<int> E IEnumerable<double> non devi preoccuparti: se passi il tipo sbagliato il tuo codice non verrà comunque compilato.
Non vi è alcuna preoccupazione per la sicurezza dei tipi, poiché var È non dinamico.È solo magia del compilatore e qualsiasi tipo di chiamata non sicura effettuata verrà catturata.
Var è assolutamente necessario per Linq:
var anonEnumeration =
from post in AllPosts()
where post.Date > oldDate
let author = GetAuthor( post.AuthorId )
select new {
PostName = post.Name,
post.Date,
AuthorName = author.Name
};
Ora guarda anonEnumerazione in intellisense e apparirà qualcosa di simile IEnumerable<'a>
foreach( var item in anonEnumeration )
{
//VS knows the type
item.PostName; //you'll get intellisense here
//you still have type safety
item.ItemId; //will throw a compiler exception
}
Il compilatore C# è piuttosto intelligente: i tipi anon generati separatamente avranno lo stesso tipo generato se le loro proprietà corrispondono.
A parte questo, finché hai l'intellisense ha senso usarlo var ovunque il contesto sia chiaro.
//less typing, this is good
var myList = new List<UnreasonablyLongClassName>();
//also good - I can't be mistaken on type
var anotherList = GetAllOfSomeItem();
//but not here - probably best to leave single value types declared
var decimalNum = 123.456m;
Immagino che dipenda dalla tua prospettiva.Personalmente non ho mai avuto difficoltà a comprendere un pezzo di codice a causa di var "abuso", e io e i miei colleghi lo usiamo parecchio ovunque.(Sono d'accordo sul fatto che Intellisense sia di grande aiuto in questo senso.) Lo accolgo con favore come un modo per rimuovere le complicazioni ripetitive.
Dopotutto, se le dichiarazioni piacciono
var index = 5; // this is supposed to be bad
var firstEligibleObject = FetchSomething(); // oh no what type is it
// i am going to die if i don't know
se fosse davvero così impossibile affrontarlo, nessuno utilizzerebbe linguaggi tipizzati dinamicamente.
Utilizzo var solo quando è chiaro quale tipo viene utilizzato.
Ad esempio, in questo caso utilizzerei var, perché puoi vedere immediatamente che x sarà del tipo "MyClass":
var x = new MyClass();
NON utilizzerei var in casi come questo, perché devi trascinare il mouse sul codice e guardare il suggerimento per vedere che tipo restituisce MyFunction:
var x = MyClass.MyFunction();
Soprattutto, io Mai usa var nei casi in cui il lato destro non è nemmeno un metodo, ma solo un valore:
var x = 5;
(perché il compilatore non può sapere se voglio un byte, short, int o altro)
Per me, l'antipatia verso var illustra perché il bilinguismo in .NET è importante.Ai programmatori C# che hanno utilizzato anche VB .NET, i vantaggi di var sono intuitivamente ovvi.La dichiarazione C# standard di:
List<string> whatever = new List<string>();
è l'equivalente, in VB .NET, di digitare questo:
Dim whatever As List(Of String) = New List(Of String)
Nessuno lo fa in VB .NET, però.Sarebbe sciocco, perché fin dalla prima versione di .NET sei stato in grado di farlo...
Dim whatever As New List(Of String)
...che crea la variabile e la inizializza tutta in una riga ragionevolmente compatta.Ah, ma cosa succede se vuoi un IList<string>, non un List<string>?Bene, in VB .NET ciò significa che devi fare questo:
Dim whatever As IList(Of String) = New List(Of String)
Proprio come dovresti fare in C# e ovviamente non potresti usarlo var per:
IList<string> whatever = new List<string>();
Se tu Bisogno il tipo per essere qualcosa di diverso, può esserlo.Ma uno dei principi base di una buona programmazione è ridurre la ridondanza, ed è esattamente ciò che fa var.
Usalo per i tipi anonimi: ecco a cosa serve.Qualsiasi altra cosa è un'utilità troppo lontana.Come molte persone cresciute in C, sono abituato a guardare il tipo a sinistra della dichiarazione.Non guardo il lato destro a meno che non sia necessario.Utilizzando var perché ogni vecchia dichiarazione mi costringe a farlo continuamente, cosa che personalmente trovo scomoda.
Coloro che dicono "non importa, usa ciò di cui sei soddisfatto" non vedono il quadro completo.Tutti prima o poi prenderanno in mano il codice di altre persone e dovranno affrontare qualunque decisione abbiano preso nel momento in cui lo hanno scritto.È già abbastanza brutto dover avere a che fare con convenzioni di denominazione radicalmente diverse, o - la classica lamentela - con stili di rinforzo, senza aggiungere il tutto 'var o no, qualcosa nel mix.Il caso peggiore sarà quello in cui un programmatore non ha utilizzato var e poi arriva un manutentore che lo adora ed estende il codice utilizzandolo.Quindi ora hai un pasticcio empio.
Gli standard sono una buona cosa proprio perché significano che è molto più probabile che tu sia in grado di raccogliere codice casuale e di essere in grado di individuarlo rapidamente.Più cose sono diverse, più diventa difficile.E il passaggio allo stile "var ovunque" rende a grande differenza.
Non mi dispiace la digitazione dinamica e non mi dispiace la digitazione implicita, nelle lingue progettate per loro.Mi piace abbastanza Python.Ma C# è stato progettato come un linguaggio tipizzato in modo statico esplicito e tale dovrebbe rimanere.Infrangere le regole per i tipi anonimi era già abbastanza grave;lasciare che le persone vadano oltre e rompano ancora di più gli idiomi della lingua è qualcosa di cui non sono soddisfatto.Ora che il genio è uscito dalla lampada, non vi rientrerà mai più.C# verrà balcanizzato nei campi.Non bene.
Molte volte durante i test, mi ritrovo ad avere un codice come questo:
var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
Console.WriteLine(something);
Ora, a volte, vorrò vedere cosa contiene SomeOtherThing stesso, SomeOtherThing non è dello stesso tipo restituito da CallMethod().Dato che sto usando var, cambio semplicemente questo:
var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
a questa:
var something = myObject.SomeProperty.SomeOtherThing;
Senza var, dovrei continuare a modificare anche il tipo dichiarato sul lato sinistro.So che è minore, ma è estremamente conveniente.
Per gli appassionati che pensano var fa risparmiare tempo, sono necessarie meno pressioni di tasti per digitare:
StringBuilder sb = new StringBuilder();
di
var sb = new StringBuilder();
Contali se non mi credi...
19 contro 21
Se necessario ti spiegherò, ma provaci...(a seconda dello stato attuale del tuo intellisense potresti doverne digitare un paio in più per ognuno)
Ed è vero per ogni tipo a cui puoi pensare!!
La mia sensazione personale è che var non dovrebbe mai essere usato tranne quando il tipo non è noto perché riduce la leggibilità del riconoscimento nel codice.Il cervello impiega più tempo a riconoscere il tipo che una linea intera.I veterani che capiscono il codice macchina e i bit sanno esattamente di cosa sto parlando.Il cervello elabora in parallelo e quando usi var lo costringi a serializzare il suo input.Perché qualcuno dovrebbe voler far lavorare di più il proprio cervello?Ecco a cosa servono i computer.
Ho diviso var ovunque, gli unici posti discutibili per me sono i tipi brevi interni, ad es.preferisco int i = 3; Sopra var i = 3;
Può certamente rendere le cose più semplici, dal codice che ho scritto ieri:
var content = new Queue<Pair<Regex, Func<string, bool>>>();
...
foreach (var entry in content) { ... }
Sarebbe estremamente prolisso senza var.
Addendum:Un po 'di tempo trascorso con una lingua con vero inferenza del tipo (es.F#) mostrerà quanto siano bravi i compilatori a ottenere il tipo giusto di espressioni.Certamente ha significato che tendo a usare var per quanto posso, e l'utilizzo di un tipo esplicito ora indica che la variabile non è del tipo dell'espressione di inizializzazione.
Nessuno, tranne per il fatto che non è necessario scrivere due volte il nome del tipo. http://msdn.microsoft.com/en-us/library/bb383973.aspx
