Verwendung des Schlüsselworts var in C#

Question

Nach einer Diskussion mit Kollegen über die Verwendung des Schlüsselworts "var" in C# 3 habe ich mich gefragt, welche Meinung die Leute zur angemessenen Verwendung der Typinferenz über var haben?

Zum Beispiel habe ich var in fragwürdigen Situationen ziemlich faul 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 Verwendungszwecke von var sind folgende:-

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, was daraus resultiert, dass es sich um einen Typ handelt, der IEnumerable implementiert, aber es ist nicht ganz so offensichtlich wie bei einer var, die ein neues Objekt deklariert.

Noch schlimmer ist es, wenn es um LINQ to objects geht, z.B.:-

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

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

Es gibt hier ein echtes Problem mit der Typsicherheit - wenn wir zum Beispiel die Ergebnisse dieser Abfrage in eine überladene Methode stellen würden, die IEnumerable<int> und IEnumerable<double> akzeptiert, könnte der Aufrufer versehentlich den falschen Typ übergeben.

var fait eine starke Typisierung beibehalten, aber die Frage ist, ob es gefährlich ist, wenn der Typ bei der Definition nicht sofort ersichtlich ist, was noch verstärkt wird, wenn Überladungen bedeuten, dass Compilerfehler nicht ausgegeben werden, wenn Sie einer Methode versehentlich den falschen Typ übergeben.

Answer 1

Für die Liebhaber, die denken var spart Zeit, da weniger Tastenanschläge erforderlich sind:

StringBuilder sb = new StringBuilder();

als

var sb = new StringBuilder();

Zähle sie, wenn du mir nicht glaubst...

19 gegen 21

Ich erkläre es, wenn ich muss, aber versuchen Sie es einfach... (je nach dem aktuellen Stand Ihrer Intellisense müssen Sie vielleicht ein paar mehr für jedes einzelne eingeben)

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

Ich persönlich bin der Meinung, dass var nie verwendet werden sollte, es sei denn, der Typ ist nicht bekannt, da es die Lesbarkeit des Codes verringert. Das Gehirn braucht länger, um den Typ zu erkennen, als eine ganze Zeile. Alte Hasen, 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 mehr arbeiten lassen wollen? Dafür gibt es doch Computer.

Answer 2

Verwenden Sie sie für anonyme Typen - dafür ist sie da. Alles andere geht zu weit. Wie viele Leute, die mit C aufgewachsen sind, bin ich es gewohnt, links von der Deklaration nach dem Typ zu suchen. Ich schaue nicht auf die rechte Seite, wenn ich nicht muss. Verwendung von var für irgendeine alte Erklärung macht mich das die ganze Zeit, was ich persönlich unangenehm finde.

Diejenigen, die sagen: "Es ist egal, verwenden Sie das, womit Sie zufrieden sind", sehen nicht das ganze Bild. Jeder wird irgendwann den Code anderer Leute übernehmen und sich mit den Entscheidungen auseinandersetzen müssen, die diese zu dem Zeitpunkt getroffen haben, als sie ihn geschrieben haben. Es ist schon schlimm genug, sich mit radikal unterschiedlichen Namenskonventionen oder - der klassische Kritikpunkt - mit Klammern auseinandersetzen zu müssen, ohne dass man auch noch das ganze ' var oder nicht" in den Mix einbringen. Der schlimmste Fall wäre, wenn ein Programmierer nicht die var und dann kommt ein Betreuer daher, der es liebt und den Code damit erweitert. Jetzt haben Sie also ein unheiliges Durcheinander.

Standards sind eine gute Sache, gerade weil sie bedeuten, dass man viel eher in der Lage ist, zufälligen Code in die Hand zu nehmen und ihn schnell zu verstehen. Je mehr Dinge unterschiedlich sind, desto schwieriger wird das. Und die Umstellung auf den "var everywhere"-Stil macht eine groß Unterschied.

Ich habe nichts gegen dynamische Typisierung, und ich habe nichts gegen implizite Typisierung - in Sprachen, die dafür ausgelegt sind. Ich mag Python sehr. Aber C# wurde als statische, explizit typisierte Sprache entwickelt und so sollte es auch bleiben. Die Regeln für anonyme Typen zu brechen war schon schlimm genug; dass die Leute das noch weiter treiben und die Idiome der Sprache noch mehr brechen, ist etwas, mit dem ich nicht glücklich bin. Jetzt, wo der Geist aus der Flasche ist, wird er nie mehr zurückkehren. C# wird sich in verschiedene Lager aufspalten. Das ist nicht gut.

Answer 3

In den meisten Fällen ist es einfach einfacher, sie zu tippen - stellen Sie sich vor

var sb = new StringBuilder();

anstelle von:

StringBuilder sb = new StringBuilder();

Manchmal ist es erforderlich, zum Beispiel: anonyme Typen, wie.

var stuff = new { Name = "Me", Age = 20 };

Ich persönlich verwende sie gerne, auch wenn sie den Code weniger lesbar und wartbar macht.

Answer 4

Der Code, den ich gestern geschrieben habe, kann die Dinge sicherlich einfacher machen:

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

Dies wäre extrem langatmig gewesen ohne var .

Nachtrag: Ein wenig Zeit mit einer Sprache verbracht, die real Typinferenz (z.B. F#) wird zeigen, wie gut Compiler den Typ von Ausdrücken richtig einschätzen können. Das hat sicherlich dazu geführt, dass ich dazu neige, die var und die Verwendung eines expliziten Typs zeigt nun an, dass die Variable nicht vom Typ des initialisierenden Ausdrucks ist.

Answer 5

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