Verwendung des Schlüsselworts var in C#

https://stackoverflow.com/questions/41479

09-06-2019
|

Frage

Nach einer Diskussion mit Kollegen über die Verwendung des Schlüsselworts „var“ in C# 3 habe ich mich gefragt, welche Meinungen die Leute über die angemessene Verwendung der Typinferenz über var haben?

Zum Beispiel habe ich var unter fragwürdigen Umständen eher träge verwendet, z. B.:-

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.

Weitere legitime Verwendungen von var sind wie folgt:

var l = new List<string>(); // Obvious what l will be.
var s = new SomeClass(); // Obvious what s will be.

Interessanterweise scheint LINQ eine Art Grauzone zu sein, z. B.: -

var results = from r in dataContext.SomeTable
              select r; // Not *entirely clear* what results will be here.

Es ist klar, welche Ergebnisse daraus resultieren, dass es sich um einen Typ handelt, der IEnumerable implementiert, es ist jedoch nicht ganz offensichtlich, so wie es bei einer Variable der Fall ist, die ein neues Objekt deklariert.

Noch schlimmer ist es, wenn es um LINQ für Objekte geht, z. B.:-

var results = from item in someList
              where item != 3
              select item;

Dies ist nicht besser als das Äquivalent foreach(var item in someList) { // ...} äquivalent.

Hier bestehen echte Bedenken hinsichtlich der Typsicherheit. Wenn wir beispielsweise die Ergebnisse dieser Abfrage in eine überladene Methode einfügen würden, die IEnumerable<int> und IEnumerable<double> akzeptiert, könnte der Aufrufer versehentlich den falschen Typ übergeben.

var tut Behalten Sie eine starke Typisierung bei, aber die Frage ist wirklich, ob es gefährlich ist, wenn der Typ bei der Definition nicht sofort erkennbar ist. Dies wird noch verstärkt, wenn Überladungen dazu führen, dass Compilerfehler möglicherweise nicht ausgegeben werden, wenn Sie unbeabsichtigt den falschen Typ an eine Methode übergeben.

Lösung

Ich denke immer noch var kann in manchen Fällen den Code besser lesbar machen.Wenn ich eine Customer-Klasse mit einer Orders-Eigenschaft habe und diese einer Variablen zuweisen möchte, mache ich einfach Folgendes:

var orders = cust.Orders;

Es ist mir egal, ob Customer.Orders es ist IEnumerable<Order>, ObservableCollection<Order> oder BindingList<Order> - Alles, was ich möchte, ist, diese Liste im Speicher zu behalten, um sie später zu durchlaufen oder ihre Anzahl oder ähnliches zu ermitteln.

Vergleichen Sie die obige Erklärung mit:

ObservableCollection<Order> orders = cust.Orders;

Für mich ist der Typname nur Rauschen.Und wenn ich zurückgehe und beschließe, den Typ der Kundenbestellungen später zu ändern (z. B. von ObservableCollection<Order> Zu IList<Order>), dann muss ich auch diese Deklaration ändern – was ich nicht tun müsste, wenn ich überhaupt var verwendet hätte.

Andere Tipps

ich benutze var ausführlich.Es wurde kritisiert, dass dies die Lesbarkeit des Codes beeinträchtigt, es gibt jedoch kein Argument, das diese Behauptung stützt.

Zugegebenermaßen kann es bedeuten, dass nicht klar ist, um welche Art es sich handelt.Na und?Das ist eigentlich der Sinn eines entkoppelten Designs.Im Umgang mit Schnittstellen sind Sie mit Nachdruck dabei nicht Ich interessiere mich für den Typ einer Variablen. var geht zwar viel weiter, aber ich denke, dass das Argument aus Sicht der Lesbarkeit dasselbe bleibt:Den Programmierer sollte eigentlich nicht der Typ der Variablen interessieren, sondern vielmehr, was eine Variable ist tut.Aus diesem Grund nennt Microsoft die Typinferenz auch „Duck Typing“.

Was macht also eine Variable, wenn ich sie mit deklariere? var?Ganz einfach, es macht alles, was IntelliSense mir sagt.Jede Argumentation zu C#, die die IDE ignoriert, bleibt hinter der Realität zurück.In der Praxis wird jeder C#-Code in einer IDE programmiert, die IntelliSense unterstützt.

Wenn ich ein verwende var Wenn ich eine deklarierte Variable verwende und nicht weiß, wofür die Variable da ist, stimmt etwas grundlegend mit meinem Code nicht. var ist nicht die Ursache, sondern macht nur die Symptome sichtbar.Geben Sie nicht dem Boten die Schuld.

Jetzt hat das C#-Team eine Codierungsrichtlinie veröffentlicht, die dies besagt var sollen nur kann verwendet werden, um das Ergebnis einer LINQ-Anweisung zu erfassen, die einen anonymen Typ erstellt (da wir hier keine wirkliche Alternative dazu haben). var).Naja, scheiß drauf.Solange mir das C#-Team kein stichhaltiges Argument für diese Richtlinie liefert, werde ich sie ignorieren, da sie meiner beruflichen und persönlichen Meinung nach purer Unsinn ist.(Entschuldigung;Ich habe keinen Link zu der betreffenden Richtlinie.)

Tatsächlich gibt es einige (oberflächlich betrachtet) gute Erklärungen warum Sie es nicht verwenden sollten var aber ich glaube immer noch, dass sie größtenteils falsch liegen.Nehmen Sie das Beispiel „Suchbarkeit“:Das behauptet der Autor var macht es schwierig, nach Orten zu suchen, an denen MyType wird eingesetzt.Rechts.Das gilt auch für Schnittstellen.Warum sollte ich eigentlich wissen wollen, wo die Klasse verwendet wird?Es könnte mich mehr interessieren, wo es instanziiert wird, und es wird weiterhin durchsuchbar sein, da irgendwo sein Konstruktor aufgerufen werden muss (selbst wenn dies indirekt geschieht, muss der Typname irgendwo erwähnt werden).

Var ist meiner Meinung nach in C# ein gute Sache^tm.Jede so typisierte Variable ist immer noch stark typisiert, erhält ihren Typ jedoch von der rechten Seite der Zuweisung, wo sie definiert ist.Da die Typinformationen auf der rechten Seite verfügbar sind, ist es in den meisten Fällen unnötig und zu ausführlich, sie auch auf der linken Seite eingeben zu müssen.Ich denke, dass dies die Lesbarkeit erheblich erhöht, ohne die Typsicherheit zu beeinträchtigen.

Aus meiner Sicht ist die Verwendung guter Namenskonventionen für Variablen und Methoden aus Sicht der Lesbarkeit wichtiger als explizite Typinformationen.Wenn ich die Typinformationen benötige, kann ich jederzeit mit der Maus über die Variable fahren (in VS) und sie abrufen.Im Allgemeinen sollten explizite Typinformationen für den Leser jedoch nicht erforderlich sein.Für den Entwickler erhalten Sie in VS immer noch Intellisense, unabhängig davon, wie die Variable deklariert ist.Trotzdem kann es immer noch Fälle geben, in denen es sinnvoll ist, den Typ explizit zu deklarieren – vielleicht haben Sie eine Methode, die a zurückgibt List<T>, aber Sie möchten es als behandeln IEnumerable<T> in deiner Methode.Um sicherzustellen, dass Sie die Schnittstelle verwenden, kann dies durch die Deklaration der Variablen des Schnittstellentyps explizit gemacht werden.Oder vielleicht möchten Sie eine Variable ohne Anfangswert deklarieren – weil sie aufgrund einer Bedingung sofort einen Wert erhält.In diesem Fall benötigen Sie den Typ.Wenn die Typinformationen nützlich oder notwendig sind, verwenden Sie sie.Ich bin jedoch der Meinung, dass es normalerweise nicht notwendig ist und der Code ohne es in den meisten Fällen einfacher zu lesen ist.

Keines davon ist absolut wahr; var kann sowohl positive als auch negative Auswirkungen auf die Lesbarkeit haben.Meiner Meinung nach, var sollte verwendet werden, wenn eine der folgenden Bedingungen zutrifft:

Der Typ ist anonym (naja, Sie haben hier keine Wahl, da er muss in diesem Fall var sein)
Der Typ ist anhand des zugewiesenen Ausdrucks offensichtlich (d. h. var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

var hat keine Auswirkungen auf die Leistung, da es sich um syntaktischen Zucker handelt;Der Compiler leitet den Typ ab und definiert ihn, sobald er in IL kompiliert wurde.da ist nichts Genau genommen dynamisch darüber.

Von Eric Lippert, einem Senior Software Design Engineer im C#-Team:

Warum war das var Stichwort eingeführt?

Es gibt zwei Gründe, die heute existieren und in 3,0 auftreten werden.

Der erste Grund ist, dass dieser Code aufgrund all der Redundanz unglaublich hässlich ist:

Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();

Und das ist ein einfaches Beispiel - ich habe schlechter geschrieben.Jedes Mal, wenn Sie gezwungen sind, zweimal genau das Gleiche zu tippen, ist dies eine Redundanz, die wir entfernen können.Viel schöner zu schreiben

var mylists = new Dictionary<string,List<int>>();

und lassen Sie den Compiler herausfinden, was der Typ auf der Zuordnung basiert.

Zweitens führt C# 3.0 anonyme Typen ein.Da anonyme Typen per Definition keine Namen haben, haben Sie Sie brauchen in der Lage zu sein, den Typ der Variablen aus dem Initialisierungsausdruck abzuleiten, wenn sein Typ anonym ist.

Hervorhebung von mir.Der ganze Artikel, C# 3.0 ist immer noch statisch typisiert, ehrlich!, und das Folgende Serie sind ziemlich gut.

Das ist was var ist für.Andere Anwendungen werden wahrscheinlich nicht so gut funktionieren.Jeder Vergleich mit JScript, VBScript oder dynamischer Typisierung ist völliger Unsinn.Beachten Sie noch einmal, var Ist erforderlich damit bestimmte andere Funktionen in .NET funktionieren.

Ich denke, die Verwendung von var sollte mit klug gewählten Variablennamen verbunden sein.

Ich habe kein Problem damit, var in einer foreach-Anweisung zu verwenden, vorausgesetzt, es ist nicht so:

foreach (var c in list) { ... }

Wenn es eher so wäre:

foreach (var customer in list) { ... }

...Dann würde jemand, der den Code liest, mit größerer Wahrscheinlichkeit verstehen, was „Liste“ ist.Wenn Sie die Kontrolle über den Namen der Listenvariablen selbst haben, ist das sogar noch besser.

Das Gleiche kann auch für andere Situationen gelten.Das ist ziemlich nutzlos:

var x = SaveFoo(foo);

...aber das macht Sinn:

var saveSucceeded = SaveFoo(foo);

Jeder für sich, schätze ich.Ich habe Folgendes getan, was einfach verrückt ist:

var f = (float)3;

Ich brauche eine Art 12-Schritte-Var-Programm.Mein Name ist Matt und ich (missbrauche) var.

Wir haben den Ethos „Code für Menschen, nicht für Maschinen“ übernommen, basierend auf der Annahme, dass man im Wartungsmodus um ein Vielfaches länger verbringt als mit der Neuentwicklung.

Für mich schließt das das Argument aus, dass der Compiler „weiß“, um welchen Typ es sich bei der Variablen handelt – natürlich können Sie beim ersten Mal keinen ungültigen Code schreiben, weil der Compiler die Kompilierung Ihres Codes stoppt, aber wenn der nächste Entwickler den Code liest Innerhalb von sechs Monaten müssen sie in der Lage sein, abzuleiten, was die Variable richtig oder falsch macht, und die Ursache von Problemen schnell zu identifizieren.

Daher,

var something = SomeMethod();

ist durch unsere Codierungsstandards verboten, aber Folgendes wird in unserem Team gefördert, weil es die Lesbarkeit erhöht:

var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
   DoWork( item ); 
}

Das ist nicht schlecht, es ist eher eine Stilsache, die tendenziell subjektiv ist.Es kann zu Inkonsistenzen kommen, wenn Sie var verwenden und wenn nicht.

Ein weiterer besorgniserregender Fall: Im folgenden Aufruf können Sie den zurückgegebenen Typ nicht anhand des Codes erkennen CallMe:

var variable = CallMe();

Das ist meine Hauptbeschwerde gegen Var.

Ich verwende var, wenn ich anonyme Delegaten in Methoden deklariere. Irgendwie sieht var sauberer aus, als wenn ich es verwenden würde Func.Betrachten Sie diesen Code:

var callback = new Func<IntPtr, bool>(delegate(IntPtr hWnd) {
   ...
});

BEARBEITEN:Das letzte Codebeispiel wurde basierend auf Julians Eingabe aktualisiert

Var ist überhaupt keine Variante.Die Variable ist immer noch stark typisiert, Sie müssen lediglich keine Tasten drücken, um dies zu erreichen.Sie können in Visual Studio mit der Maus darüber fahren, um den Typ anzuzeigen.Wenn Sie gedruckten Code lesen, müssen Sie möglicherweise ein wenig nachdenken, um herauszufinden, um welchen Typ es sich handelt.Aber es gibt nur eine Zeile, die es deklariert, und viele Zeilen, die es verwenden. Deshalb ist es immer noch die beste Möglichkeit, den Dingen anständige Namen zu geben, damit Ihr Code leichter verständlich ist.

Ist die Verwendung von Intellisense faul?Es ist weniger mühsam zu tippen als der ganze Name.Oder gibt es Dinge, die weniger Arbeit machen, aber keine Kritik verdienen?Ich denke, das gibt es, und var ist einer von ihnen.

Die wahrscheinlichste Zeit, in der Sie dies benötigen, ist für anonyme Typen (wo es zu 100 % erforderlich ist).aber es vermeidet auch Wiederholungen in den trivialen Fällen, und meiner Meinung nach macht es die Linie klarer.Für eine einfache Initialisierung muss ich den Typ nicht zweimal sehen.

Zum Beispiel:

Dictionary<string, List<SomeComplexType<int>>> data = new Dictionary<string, List<SomeComplexType<int>>>();

(Bitte bearbeiten Sie den hscroll oben nicht – das beweist irgendwie den Punkt!!!)

vs:

var data = new Dictionary<string, List<SomeComplexType<int>>>();

Es gibt jedoch Fälle, in denen dies irreführend ist und möglicherweise Fehler verursachen kann.Seien Sie vorsichtig bei der Verwendung var wenn die ursprüngliche Variable und der initialisierte Typ nicht identisch wären.Zum Beispiel:

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);

Ein konkreter Fall, in dem var schwierig ist:Offline-Codeüberprüfungen, insbesondere solche, die auf Papier durchgeführt werden.

Dabei kann man sich nicht auf Mouseovers verlassen.

Ich verstehe nicht, was die große Sache ist.

var something = someMethod(); // Type of 'something' not clear <-- not to the compiler!

Sie haben immer noch die volle Intelligenz für „etwas“, und für jeden unklaren Fall haben Sie Ihre Unit-Tests, oder?( Tust du?)

Es ist kein Varchar, es ist nicht dunkel und es ist sicherlich keine dynamische oder schwache Eingabe.Es stoppt Wahnsinn wie diesen:

List<somethinglongtypename> v = new List<somethinglongtypename>();

und diese totale Gedankenverwirrung reduzieren auf:

var v = new List<somethinglongtypename>();

Schön, nicht ganz so schön wie:

v = List<somethinglongtypename>();

Aber genau das ist es dann Buh ist für.

Wenn jemand das verwendet var Schlüsselwort, weil sie nicht „den Typ herausfinden“ wollen, das ist definitiv der falsche Grund.Der var Das Schlüsselwort erstellt keine Variable mit einem dynamischen Typ, der Compiler muss den Typ dennoch kennen.Da die Variable immer einen bestimmten Typ hat, sollte der Typ nach Möglichkeit auch im Code erkennbar sein.

Gute Gründe, das zu nutzen var Stichwort sind zum Beispiel:

Dort wo es benötigt wird, d.h.um eine Referenz für einen anonymen Typ zu deklarieren.
Wo dadurch der Code besser lesbar wird, d. h.Entfernen sich wiederholender Erklärungen.

Das Ausschreiben des Datentyps erleichtert häufig die Verständlichkeit des Codes.Es zeigt, welche Datentypen Sie verwenden, sodass Sie den Datentyp nicht erst herausfinden müssen, was der Code bewirkt.

Angesichts der Leistungsfähigkeit von Intellisense bin ich mir nicht sicher, ob var schwieriger zu lesen ist als Mitgliedsvariablen in einer Klasse oder lokale Variablen in einer Methode, die außerhalb des sichtbaren Bildschirmbereichs definiert werden.

Wenn Sie eine Codezeile haben, z

IDictionary<BigClassName, SomeOtherBigClassName> nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

Es ist viel einfacher oder schwerer zu lesen als:

var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

Ich denke, das Wichtigste bei VAR ist, es nur dort einzusetzen, wo es angemessen ist, d. h.wenn Sie Dinge in Linq tun, die es erleichtert (und wahrscheinlich auch in anderen Fällen).

Wenn ja bekommen einen Typ für etwas, dann sollten Sie ihn verwenden – dies nicht zu tun ist einfache Faulheit (im Gegensatz zu kreativer Faulheit, die im Allgemeinen gefördert werden sollte – gute Programmierer arbeiten oft sehr hart, um faul zu sein und könnten als die Quelle der Sache angesehen werden an erster Stelle).

Ein pauschales Verbot ist genauso schlimm wie der Missbrauch des Konstrukts überhaupt, es muss jedoch ein vernünftiger Kodierungsstandard vorhanden sein.

Beachten Sie außerdem, dass es sich nicht um eine Variable vom Typ VB handelt, da sie den Typ nicht ändern kann Ist Eine stark typisierte Variable bedeutet nur, dass der Typ abgeleitet wird (weshalb es Leute gibt, die argumentieren, dass es nicht unvernünftig ist, sie beispielsweise in einem foreach zu verwenden, aber ich würde aus Gründen der Lesbarkeit und Wartbarkeit nicht zustimmen).

Ich vermute, dass dieser laufen und laufen wird (-:

Murph

Sicher, int ist einfach, aber wenn der Typ der Variablen ist IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var macht die Sache viel einfacher.

Gestohlen von der Beitrag zu diesem Thema bei CodingHorror:

Leider haben Sie und alle anderen ziemlich viel falsch verstanden.Ich stimme zwar mit Ihnen überein, dass Redundanz keine gute Sache ist, aber der bessere Weg, dieses Problem zu lösen, wäre Folgendes gewesen:

MyObject m = new();

Oder wenn Sie Parameter übergeben:

Person p = new("Vorname", "Nachname);

Bei der Erstellung eines neuen Objekts leitet der Compiler den Typ von der linken und nicht von der rechten Seite ab.Dies hat weitere Vorteile gegenüber „var“, da es auch in Felddeklarationen verwendet werden könnte (es gibt auch einige andere Bereiche, in denen es ebenfalls nützlich sein könnte, aber ich werde hier nicht näher darauf eingehen).

Letztendlich war es einfach nicht beabsichtigt, die Redundanz zu reduzieren.Verstehen Sie mich nicht falsch, „var“ ist in C# für anonyme Typen/Projektionen SEHR wichtig, aber die Verwendung hier ist einfach VIEL daneben (und das sage ich schon seit langer, langer Zeit), da Sie den Typ dadurch verschleiern wird benutzt.Es ist zu oft, es zweimal eingeben zu müssen, aber es null Mal deklarieren zu müssen, ist zu selten.

Nicholas Paldino .NET/C# MVP am 20. Juni 2008, 08:00 Uhr

Ich denke, wenn Ihr Hauptanliegen darin besteht, weniger tippen zu müssen, dann gibt es kein Argument, das Sie davon abhalten könnte, es zu verwenden.

Wenn du nur gehst immer Seien Sie die Person, die sich Ihren Code ansieht. Wen interessiert das dann?Ansonsten gilt in einem Fall wie diesem:

var people = Managers.People

Es ist in Ordnung, aber in einem Fall wie diesem:

var fc = Factory.Run();

Es schließt alle unmittelbaren Schlussfolgerungen aus, die mein Gehirn aus dem „Englisch“ des Codes ziehen könnte.

Ansonsten nutzen Sie einfach Ihr bestes Urteilsvermögen und programmieren Sie mit „Höflichkeit“ gegenüber anderen, die möglicherweise an Ihrem Projekt arbeiten müssen.

Benutzen var anstelle eines expliziten Typs macht Refactorings viel einfacher (daher muss ich den vorherigen Postern widersprechen, die meinten, es mache keinen Unterschied oder es sei reiner „syntaktischer Zucker“).

Sie können den Rückgabetyp Ihrer Methoden ändern, ohne jede Datei zu ändern, in der diese Methode aufgerufen wird.Vorstellen

...
List<MyClass> SomeMethod() { ... }
...

was wie verwendet wird

...
IList<MyClass> list = obj.SomeMethod();
foreach (MyClass c in list)
  System.Console.WriteLine(c.ToString());
...

Wenn Sie umgestalten wollten SomeMethod() eine zurückgeben IEnumerable<MySecondClass>, müssten Sie die Variablendeklaration ändern (auch innerhalb der foreach) an jedem Ort, an dem Sie die Methode verwendet haben.

Wenn du schreibst

...
var list = obj.SomeMethod();
foreach (var element in list)
  System.Console.WriteLine(element.ToString());
...

Stattdessen müssen Sie es nicht ändern.

@aku:Ein Beispiel sind Codeüberprüfungen.Ein weiteres Beispiel sind Refactoring-Szenarien.

Grundsätzlich möchte ich nicht mit meiner Maus auf Typensuche gehen.Es ist möglicherweise nicht verfügbar.

Es ist Geschmackssache.All diese Aufregung um das Typ einer Variablen verschwindet, wenn Sie sich an dynamisch typisierte Sprachen gewöhnen.Das ist, Wenn Du fängst jemals an, sie zu mögen (ich bin nicht sicher, ob das jeder kann, aber ich schon).

C#s var ist darin ziemlich cool sieht aus wie dynamisches Tippen, ist es aber tatsächlich statisch Eingabe – der Compiler erzwingt die korrekte Verwendung.

Der Typ Ihrer Variablen ist nicht wirklich wichtig (das wurde bereits gesagt).Es sollte aus dem Kontext (seine Interaktionen mit anderen Variablen und Methoden) und seinem Namen relativ klar hervorgehen – das ist nicht zu erwarten Kundenliste eine enthalten int...

Ich warte immer noch darauf, was mein Chef zu dieser Angelegenheit denkt – ich habe die generelle Erlaubnis, alle neuen Konstrukte in 3.5 zu verwenden, aber was werden wir mit der Wartung tun?

In Ihrem Vergleich zwischen IEnumerable<int> Und IEnumerable<double> Sie brauchen sich keine Sorgen zu machen – wenn Sie den falschen Typ übergeben, wird Ihr Code sowieso nicht kompiliert.

Es gibt keine Bedenken hinsichtlich der Typsicherheit, da var Ist nicht dynamisch.Es ist nur Compiler-Magie und alle unsicheren Aufrufe, die Sie tätigen, werden abgefangen.

Var wird für Linq unbedingt benötigt:

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
    };

Schauen Sie sich jetzt an anonEnumeration in intellisense und es wird so etwas wie aussehen 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
}

Der C#-Compiler ist ziemlich clever – separat generierte Anon-Typen haben denselben generierten Typ, wenn ihre Eigenschaften übereinstimmen.

Abgesehen davon ist die Verwendung sinnvoll, solange Sie über Intellisense verfügen var Überall ist der Kontext klar.

//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;

Ich denke, es hängt von Ihrer Perspektive ab.Ich persönlich hatte nie Schwierigkeiten, einen Code zu verstehen var „Missbrauch“, und meine Kollegen und ich verwenden es überall ziemlich oft.(Ich stimme zu, dass Intellisense in dieser Hinsicht eine große Hilfe ist.) Ich begrüße es als eine Möglichkeit, sich wiederholende Probleme zu beseitigen.

Immerhin, wenn Aussagen wie

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

Wäre es wirklich unmöglich, damit umzugehen, würde niemand dynamisch typisierte Sprachen verwenden.

Ich verwende var nur, wenn klar ist, welcher Typ verwendet wird.

In diesem Fall würde ich zum Beispiel var verwenden, da man sofort sieht, dass x vom Typ „MyClass“ sein wird:

var x = new MyClass();

In solchen Fällen würde ich var NICHT verwenden, da Sie die Maus über den Code ziehen und sich den Tooltip ansehen müssen, um zu sehen, welchen Typ MyFunction zurückgibt:

var x = MyClass.MyFunction();

Vor allem ich niemals Verwenden Sie var in Fällen, in denen die rechte Seite nicht einmal eine Methode, sondern nur ein Wert ist:

var x = 5;

(weil der Compiler nicht wissen kann, ob ich ein Byte, Short, Int oder was auch immer möchte)

Für mich die Abneigung gegen var veranschaulicht, warum Zweisprachigkeit in .NET wichtig ist.Für diejenigen C#-Programmierer, die auch VB .NET gemacht haben, die Vorteile von var sind intuitiv offensichtlich.Die Standard-C#-Deklaration von:

List<string> whatever = new List<string>();

ist in VB .NET das Äquivalent der folgenden Eingabe:

Dim whatever As List(Of String) = New List(Of String)

Allerdings macht das in VB .NET niemand.Es wäre albern, denn seit der ersten Version von .NET ist das möglich...

Dim whatever As New List(Of String)

...was die Variable erstellt und alles in einer einigermaßen kompakten Zeile initialisiert.Ah, aber was ist, wenn Sie ein wollen IList<string>, kein List<string>?Nun, in VB .NET bedeutet das, dass Sie Folgendes tun müssen:

Dim whatever As IList(Of String) = New List(Of String)

Genau wie Sie es in C# tun müssten und es offensichtlich nicht verwenden könnten var für:

IList<string> whatever = new List<string>();

Wenn du brauchen Der Typ kann etwas anderes sein, es kann sein.Aber eines der Grundprinzipien guter Programmierung ist die Reduzierung von Redundanz, und genau das macht var.

Verwenden Sie es für anonyme Typen – dafür ist es da.Alles andere wäre zu weit gegriffen.Wie viele Leute, die mit C aufgewachsen sind, bin ich es gewohnt, auf der linken Seite der Deklaration nach dem Typ zu suchen.Ich schaue nicht auf die rechte Seite, es sei denn, es muss sein.Benutzen var denn jede alte Erklärung bringt mich dazu, das ständig zu tun, was mir persönlich unangenehm ist.

Wer sagt: „Es spielt keine Rolle, verwenden Sie das, womit Sie zufrieden sind“, sieht nicht das ganze Bild.Jeder wird irgendwann den Code anderer Leute in die Hand nehmen und muss sich mit den Entscheidungen auseinandersetzen, die er zum Zeitpunkt des Schreibens getroffen hat.Es ist schon schlimm genug, sich mit radikal unterschiedlichen Namenskonventionen herumschlagen zu müssen, oder – der klassische Kritikpunkt – mit Klammerstilen, ohne das Ganze hinzuzufügen.var oder nicht' Sache in die Mischung.Der schlimmste Fall wäre, wenn ein Programmierer es nicht verwendet hätte var Und dann kommt ein Betreuer, der es liebt und den Code damit erweitert.Jetzt haben Sie also ein unheiliges Durcheinander.

Standards sind gerade deshalb eine gute Sache, weil sie bedeuten, dass Sie mit größerer Wahrscheinlichkeit in der Lage sind, zufälligen Code zu erkennen und ihn schnell zu verstehen.Je mehr Dinge unterschiedlich sind, desto schwieriger wird es.Und der Wechsel zum „Var Everywhere“-Stil macht einen groß Unterschied.

Mir macht dynamisches Tippen nichts aus, und implizites Tippen macht mir nichts aus – in Sprachen, die dafür konzipiert sind.Ich mag Python sehr.Aber C# wurde als statisch explizit typisierte Sprache konzipiert und das soll auch so bleiben.Die Regeln für anonyme Typen zu brechen war schon schlimm genug;Ich bin nicht zufrieden damit, die Leute noch weiter gehen zu lassen und die Redewendungen der Sprache noch weiter zu brechen.Jetzt, wo der Geist aus der Flasche ist, wird er nie wieder hineingehen.C# wird in Lager aufgeteilt.Nicht gut.

Beim Testen fällt mir oft auf, dass ich Code wie diesen habe:

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
Console.WriteLine(something);

Manchmal möchte ich sehen, was SomeOtherThing selbst enthält. SomeOtherThing ist nicht derselbe Typ, den CallMethod() zurückgibt.Da ich jedoch var verwende, ändere ich einfach Folgendes:

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();

dazu:

var something = myObject.SomeProperty.SomeOtherThing;

Ohne var müsste ich den deklarierten Typ auch auf der linken Seite ständig ändern.Ich weiß, dass es geringfügig ist, aber es ist äußerst praktisch.

Für die Aficionados, die denken var Spart Zeit, die Eingabe erfordert weniger Tastenanschläge:

StringBuilder sb = new StringBuilder();

als

var sb = new StringBuilder();

Zählen Sie sie, wenn Sie mir nicht glauben ...

19 gegen 21

Ich werde es erklären, wenn ich muss, aber probieren Sie es einfach aus ...(Abhängig vom aktuellen Status Ihres Intellisense müssen Sie möglicherweise für jeden ein paar mehr eingeben.)

Und das gilt für jeden Typ, den Sie sich vorstellen können!!

Mein persönlicher Eindruck ist, dass var niemals verwendet werden sollte, es sei denn, der Typ ist nicht bekannt, da es die Lesbarkeit der Erkennung im Code verringert.Das Gehirn braucht länger, um den Typ zu erkennen, als eine vollständige Zeile.Oldtimer, die Maschinencode und -bits verstehen, wissen genau, wovon ich spreche.Das Gehirn verarbeitet parallel und wenn Sie var verwenden, zwingen Sie es, seine Eingaben zu serialisieren.Warum sollte jemand sein Gehirn härter arbeiten lassen wollen?Dafür sind Computer da.

Ich teile var überall auf, die einzigen für mich fragwürdigen Stellen sind interne Kurztypen, z.B.ich bevorzuge int i = 3; über var i = 3;

Es kann die Dinge sicherlich einfacher machen, anhand des Codes, den ich gestern geschrieben habe:

var content  = new Queue<Pair<Regex, Func<string, bool>>>();
...
foreach (var entry in content) { ... }

Ohne wäre das äußerst ausführlich gewesen var.

Nachtrag:Ein wenig Zeit mit einer Sprache verbracht mit real Typinferenz (z. B.F#) wird zeigen, wie gut Compiler darin sind, die Art der Ausdrücke richtig hinzubekommen.Es hat sicherlich dazu geführt, dass ich dazu neige, es zu verwenden var So viel ich kann, und die Verwendung eines expliziten Typs zeigt jetzt an, dass die Variable nicht vom Typ des Initialisierungsausdrucks ist.

Keine, außer dass Sie den Typnamen nicht zweimal schreiben müssen. http://msdn.microsoft.com/en-us/library/bb383973.aspx

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow