2009-12-15 3 views
11

Es scheint, dass mehr und mehr C# -Code ich die Kennung var Typ lesen verwendet:Gibt es einen technischen Grund, var in C# zu verwenden oder nicht, wenn der Typ bekannt ist?

foreach (var itemChange in ItemChanges) 
{ 
    //... 
} 

statt explizit Angabe der Art:

foreach (ItemChange itemChange in ItemChanges) 
{ 
    //... 
} 

selbst wenn der Typ bekannt ist.

Ich verwende immer noch die letzte explizite Version, nur weil ich denke, dass jemand später lesen wird schneller verstehen, welcher Typ eine Variable ist, als wenn Sie var verwenden.

Aber gibt es irgendeinen technischen Grund, den einen oder anderen zu verwenden?

+0

möglich Duplikat von [Was ist der Sinn des Schlüsselworts var?] (Http://stackoverflow.com/questions/209199/whats-the-point-of-the-var-keyword) –

+0

auch ein Betrüger von: http : //stackoverflow.com/questions/41479/use-of-var-keyword-in-c –

Antwort

12

Nein, nur Lesbarkeit.

+2

Ich mag diese Antwort. Kurz und bündig. – RCIX

21

Es gibt keinen technischen Grund. Wenn der Typ zur Kompilierzeit nicht abgeleitet werden kann, wird der Code nicht kompiliert.

Sie haben recht, wenn Sie angeben, dass es Fälle gibt, in denen es besser ist, einen expliziten Typ für die Lesbarkeit zu verwenden, z.

var obj = SomeMethod(); // what's the type? you'd have to inspect SomeMethod() 
SomeClass obj = SomeMethod(); // the type is obvious 

aber andere Fälle, in denen die Verwendung von var vollkommen Sinn macht, z.B.

var obj = new SomeClass(); // the type is obvious 
SomeClass obj = new SomeClass(); // the duplication of type is unnecessary 
+4

Aber (a) das gerade beweist, dass 'SomeMethod' schlecht benannt ist, nicht, dass die Typinformation nützlich ist, und (b) warum interessieren Sie sich überhaupt für den konkreten Typ? Ich sehe viele Antworten auf die "var" -Debatte, die davon ausgehen, dass konkrete Typinformationen die Lesbarkeit verbessern, ohne dass dafür irgendein Beweis angeführt wird. Benutzer von dynamischen und funktionalen Sprachen würden der Aussage, dass Inline-Typ-Informationen eine gute Sache sind, eher widersprechen. –

+1

Ich verstehe, wo Sie herkommen, aber a) Sie haben vielleicht keine Kontrolle über den Namen von 'SomeMethod' b) Ich interessiere mich nicht besonders, das ist nur ein Lesbarkeitsproblem, einige Leute vielleicht lieber in der Lage zu können kenne den Typ der Variablen, wenn sie den folgenden Code lesen c) 'Benutzer von dynamischen und funktionalen Sprachen' - fair genug. Ich mache auch etwas IronPython-Codierung und ich kann diesen Kontext verstehen. Dies ist jedoch eine C# -Frage –

2

Nr Verwendung var wo es die Lesbarkeit verbessert und umgekehrt.

2

var ist eine C# 3.x + Funktion, oder? Ohne diesen Code ist Ihr Code auch mit anderen Versionen kompatibel.

Und es gibt viele interessante Fragen in SO, wenn Sie „var C#

+0

Es ist eigentlich eine C# 3-Funktion, aber immer noch gut funktionieren, wenn Sie .Net 2.0 zielen – philsquared

+0

Nun, Var ist in .Net 2.0 als Compiler-Trick implementiert, wir verwenden es gelegentlich in unserem .Net2 .0 Anwendung. –

+0

Danke Phil Nash, Du hast Recht, Korrigiert. – YOU

3

Im Allgemeinen keinen technischen Grund suchen. Lesbarkeit - in beiden Richtungen - ist der einzige wirkliche Faktor.

Ein kleiner Vorbehalt ist jedoch, dass var den statischen Typ der Variablen ableitet. Wenn Sie einen Sub- oder Super-Class-Typ haben möchten, müssen Sie das Casting selbst durchführen. Im Fall einer foreach, wie in Ihrem Beispiel, können Sie in der Regel Downcasting durchgeführt für Sie "kostenlos" nur durch die Deklaration Ihrer Schleife Variable mit dem Unterklasse-Typ.

Das klassische Beispiel ist über eine XML-NodeList Iterieren, die Sie ist eine Liste von XmlElement wissen , aber Nodelist als eine Sammlung von XmlNode s eingegeben wird. Natürlich können Sie einen Cast oder einen as verwenden, um den gewünschten Typ zurück zu bekommen, aber das würde den Zweck der Typinferenz zu vereiteln scheinen :-)

Natürlich wird der Compiler Sie bald darüber informieren Wenn Sie versuchen, ein Mitglied des Knotens zu verwenden, der nur für XmlElement verfügbar ist, ist es immer noch nicht unbedingt ein technischer Unterschied.


andere Sache, die ein wenig ärgerlich ist, dass, wenn Sie ein Tool wie ReSharper verwenden, ist es Ihnen var in jeder möglichen Situation verwenden sehr aggressiv ist über hindeutet. Besonders ärgerlich ist es, wenn Sie zum Beispiel eine int Deklaration in eine var empfehlen!

Wenn Sie diese Funktion jedoch nicht ausschalten, erhalten Sie weniger "Rauschen" von Resharper, je mehr Sie var verwenden.

3

Der einzige technische Grund, den ich kenne, ist, dass Sie implizite Umwandlungen ohne var, z.

aber hier bevorzuge ich viel var, wie es die Besetzung explizit macht; während ich über die Typen nicht so viel Pflege ist mir egal, wenn ich eine Darstellung Wechsel Typumwandlung durchführen werde:

var a = (double)i; // explicit cast with implicit types 

Aber wirklich die allgemeine Grund ist die Lesbarkeit, wie Sie gesagt haben. Die Frage, die Sie sich stellen müssen, ist, warum Sie glauben, dass der genaue konkrete Typ für die Lesbarkeit wichtig ist? Schreiben Sie immer Linq-Abfragen, die den konkreten Typ aufrufen, z.

from ItemChange itemChange in ItemChanges 

// instead of 

from itemChange in ItemChanges 

In ähnlicher Weise rufen Sie immer die Typargumente zu generischen Methoden auf, anstatt Typinferenz zu verwenden, z.

ItemChanges.Select<ItemChange, ItemChange>((ItemChange itemChange) => ...); 

// instead of 

ItemChanges.Select(itemChange => ...); 

Oder sind Sie glücklich, den Compiler zu lassen tun einige Arbeit für Sie und lassen Sie es die Typen arbeiten, auch auf die ‚Kosten‘ der nicht die Typinformationen explizit angegeben haben?

Wenn Sie mit Typinterferenzen in Linq und generischen Methoden zufrieden sind, haben Sie bereits entschieden, dass es Ihnen gut geht, dass Sie keine Typen explizit überall angeben, und Sie haben Ihren Code wahrscheinlich nicht gefunden weniger lesbar sein (in der Tat haben Sie wahrscheinlich das Gegenteil gefunden). Die Verwendung von var ist nur ein weiterer Schritt auf demselben Pfad, auf dem Sie bereits arbeiten.

+0

Das explizite Umwandeln kann in bestimmten Situationen wichtig sein, z. B. wenn das Enumerator einer Auflistung "Objekt" anstelle des genauen Typs zurückgibt. Ich denke, SPListItemCollection ist ein solches Beispiel, aber ich denke, das gilt für alle nicht-generischen Sammlungen. –

+0

@Michael - einverstanden. Ich hätte den Unterschied zwischen Repräsentationserwägungen und Repräsentationserhaltungsmodellen (die ich am deutlichsten mit einem Darstellungsoperator formulieren möchte, sind die Repräsentationsveränderlichen) klarer. Ja, ich denke, dass die Verwendung des Typnamens klarer ist als ein Cast für die Repräsentation, die Typumwandlungen bewahrt. –

3

var eine C# 3.0-Funktion nur dann verpflichtend in anonymen Typ

Da Code folgende

var v = new { Amount = 108, Message = "Hello" }; 

dynamisch einen neuen anonymen Typ erstellen, ist var Verwendung obligatorisch ist. Zum Beispiel ist var in Linq besonders nützlich, wo Typ oft dynamisch erstellt wird.

In allen anderen Situationen ist es nur eine Frage des Geschmacks für die endgültige Anwendung (es ist während der Kompilierung gelöst). Aber für Codeleser, denke ich, ist 'var' weniger informativ als der Typ selbst.

+1

Manchmal denke ich, es sollte etwas wie ein 'anon' Schlüsselwort für diese anstelle von' var' geben. –

0

Es gibt keinen technischen Grund, var außer anonymen Typen in einem bestimmten Status des Programms zu verwenden.

Wenn Sie jedoch var verwenden, kann das Programm geändert werden, ohne dass Sie es bearbeiten müssen.Angesichts

public int SomeMethod(){} 
public List<T> SomeOtherMethod<T>(T parameter); 

dann

var x = SomeMethod(); 
var y = SomeOtherMethod(x); 

Wird arbeiten (und y wird List<int> sein). Wenn Sie

int x = SomeMethod(); 
List<int> y = SomeOtherMethod(x); 

dann benutzt hatte, wenn SomeMethod() geändert wurden zurückzukehren long, dann würden Sie die Definition von y ändern.

Ich habe diese Art von Sache in einem Programm zu verbreiten, Hunderte von Änderungen erfordern. In diesem speziellen Fall wurde der Datenzugriffscode geändert, um ReadOnlyCollection<T> statt List<T> zurückzugeben. Es waren so viele Codeänderungen erforderlich, dass ich alle expliziten Erwähnungen von List<T> in var änderte, und der Code wird sich nie wieder ändern müssen.

-1

Ja, sie sind unterschiedlich. var entfernt den ursprünglichen Datentyp und einen Datentyp-check, also ist es gefährlicher.

Typ-Kontrollen

Eine normale Variablendefinition enthält einen Datentyp-Check auf die anfängliche Zuweisung.

T a = init;  // type-checked 
a = b;   // type-checked 
a = c;   // type-checked 

Dieses fehlt, wenn Sie var

var a = init; // NOT type-checked 
a = b;   // type-checked 
a = c;   // type-checked 

Diese Kompilierung-Tests verwenden sind der Leim, die zusammen große Programme hält. Sie zu entfernen ist dumm.

versehentliche Änderungen

Eine normale Variablendefinition hat einen festen Typ - sie nicht versehentlich geändert werden kann.

Wenn Sie den ursprünglichen Datentyp entfernen, können Sie den Typ der Variablen versehentlich ändern. Jede Änderung am ursprünglichen Ausdruck kann den Datentyp der Variablen ändern.

Mit der Zeit, da die Software bearbeitet wird, könnte der Datentyp versehentlich geändert werden.
Es könnte schon passiert sein, und Sie können es nicht sagen.

Beispiel:

public double MaxValue = 1.2; 

    ... meanwhile, in another source file ... 

    var x = MaxValue - 1; 
    var y = IsFull(x); 

Sowohl x als auch Datentypen der y versehentlich durch sein Ändern MaxValue bearbeiten.
Q. Ist das schon passiert?

Zusammenfassung

var Mit schaltet sich die lokalen Variablen des Datentyps in einen ungeprüften beweglichen Teil.
Je mehr bewegliche Teile eine Maschine hat, desto wahrscheinlicher ist es zu brechen.

Explizite Datentypen verhindern Fehler.

Verwandte Themen