Hallo Code-Kickers,

wie steht Ihr zum Einsatz des C# Schlüsselwortes "var"?
Seit Ihr Gegner, Befürworter oder sogar Fans?

Ich persönlich konnte mich bisher noch nicht so sehr damit anfreunden.
Meiner Meinung nach leidet die Code-Lesbarkeit darunter.

Natürlich kann man seine Klassen und Methoden so nennen, dass sie auch trotz var lesbar und schlüssig sind. Es gibt z.B. Entwickler die vorhandenen Code strikt auf var umstellen (wird ja z.B. von Resharper so vorgeschlagen). Diese Methoden und Klassen sind in den meisten Fällen aber alles andere als gut benannt.

Ich sehe aber auch ein, dass Code-Umstellungen durch den Einsatz von "var" einfacher zu realisieren sind.

Wie ist Eure Meinung?

Gruß

CodeSniffer

Wir haben da kürzlich relativ ausführlich darüber nachgedacht. Es gibt drei Fälle, in denen wir var zulassen:

• Für anonyme Typen, denn da bleibt mir eh nichts anderes übrig. Wenn anonyme Typen in einem Projekt verwendet werden dürfen, dann muss dafür auch var zulässig sein.
  
• Für Initialisierungen, bei denen nicht nur der Compiler den Typ herleiten kann, sondern auch der Leser des Codes. Das Beispiel von nabuchodonossor halt ich schon für grenzwertig, aber noch vertretbar, wenn bei derartigen Zuweisungen klar ist, dass var in diesem Fall dem explizit angegebenen generischen Typ SerializationAttribute entspricht. Ein weiteres Beispiel ist z.B.
  

  var map = new Dictionary<Guid, Tuple<Guid, List<string>>();

  
  denn das ist eindeuting nachvollziehbar, auch für den Leser des Codes. Da wir zu 95% Code nur lesen, ist Lesbarkeit ein zentrales Qualitätskriterium für Code.
  
• Für Iterationen mit foreach.
  

  foreach(var item in list)

  
  
  Was ich für sehr gefährlich halte, ist eine Zuweisung an eine implizit mit var definierte Variable und ein Aufruf an diese mehrere/viele Zeilen später. Beispiel
  

  var item = GetItemFromSomewhere();
  // ... 
  item.DoSomething();

  
  Solange die Methode GetItemFromSomewhere() einen Type liefert, der eine gültige DoSomething() Methode unterstützt, funktioniert dieser Code einwandfrei. Wenn GetItemFromSomewhere() einen solchen Typ aus irgendeinem Grund irgendwann nicht mehr liefert, habe ich aber den Fehler in der Zeile
  
  

  item.DoSomething();

  und nicht bei der Zuweisung
  
  

  var item = GetItemFromSomewhere();

  Der Zuweisungsfehler wird also verschleppt. Davor mag man auch in den von mir genannten Fällen nicht immer sicher sein, aber es ist eben unser Konsens aus Verständlichkeit und Effizienzgewinn.
  
  Kürzlich habe ich auf Eric Lippert's blog einen serh lesenswerten und ausführlichen Blogeintrag zu dem Thema gelesen (Uses and misuses of implicit typing), auch die Kommentare dazu regen sehr zum Nachdenken an. Es ist erstaunlich, welche Argumentationsketten für und wider des var-Schlüsselworts aufgebaut werden. Das muss jeder/jedes Team für sich selber wissen, vereinbaren und einhalten. Die Entscheidung für die drei von mir oben genannten Fälle wurden auch von Lippert's Blogbeitrag noch einmal beeinflusst, wie gesagt, das ist, was wir vereinbart haben.
  

EDIT:
Zum Thema Faulheit fällt mir noch was ein: Ich ertapp mich oft, dass ich eine Zeile Code mit var beginne, fertig schreibe und danach mit Refactor->Make Explicit das var per Tool beseitige.

Gruß
Florian

Was wäre eine solche Diskussion ohne eine direkte Aussage von Microsoft? Also hier einmal einen Auschnitt zur Verwendung von var aus der MSDN:

Im folgenden Beispiel werden zwei Abfrageausdrücke veranschaulicht. Im ersten Ausdruck ist der Gebrauch von var zulässig, jedoch nicht erforderlich, da der Typ des Abfrageergebnisses explizit als IEnumerable<string> angegeben werden kann. Im zweiten Ausdruck hingegen muss var verwendet werden, da das Ergebnis eine Auflistung von anonymen Typen ist und der Name des Typs nur für den Compiler selbst zugänglich ist. Beachten Sie, dass in Beispiel 2 die foreach-Iterationsvariable item ebenfalls implizit typisiert sein muss.

// Example #1: var is optional because
// the select clause specifies a string
string[] words = { "apple", "strawberry", "grape", "peach", "banana" };
var wordQuery = from word in words
                where word[0] == 'g'
                select word;

// Because each element in the sequence is a string, 
// not an anonymous type, var is optional here also.
foreach (string s in wordQuery)
{
    Console.WriteLine(s);
}

// Example #2: var is required because
// the select clause specifies an anonymous type
var custQuery = from cust in customers
                where cust.City == "Phoenix"
                select new { cust.Name, cust.Phone };

// var must be used because each item 
// in the sequence is an anonymous type
foreach (var item in custQuery)
{
    Console.WriteLine("Name={0}, Phone={1}", item.Name, item.Phone);
}

Generell nutze ich teilweise auch ab und zu mal ein var, bin aber Fan der expliziten Typisierung wo es halt geht. Hier noch ein Link zur MSDN: Implizit typisierte lokale Variablen.

Ich versuche es sooft als irgend Möglich zu verwenden - wenn man sich mal dran gewöhnt hat, ist das Argument mit der schlechteren Lesbarkeit auch wieder passé (wie mit allem). Mittlerweile empfinde ich unnötige Typangaben als störend. Ebenso stört mich, dass var nicht überall unterstützt wird (z.B. Member-Variablen mit Default-Wert).

Ich wiederhole mich nicht gerne (DRY-Prinzip). Das gilt auch für die Variablendeklaration.
Das ist nichts, was man mit Refactoring nicht auch hinbekommen würde (entsprechende Tools vorausgesetzt), aber wozu noch ein anderes Hilfmittel verwenden, wenn die Sprache es schon unterstützt.
Bei Änderungen am Rückgabewert einer (privaten) Funktion will ich nicht unbedingt jeden Aufruf überprüfen oder gar abändern (wenn ich weiß, dass der Typ mehr oder weniger "kompatibel" ist, wie z.B. zwischen float und double). Wenn strikt var verwendet wird, muss ich nur den Rückgabetyp anpassen, den Rest decken die Tests ab, die ja sowieso in allen Projekten in Übermaß vorhanden sind *g* - sind wir nicht alle Musterschüler.

Aus gleichem Grund versuche ich - soweit Möglich - auf die Angabe des Typs bei generischen Membern zu verzichten (wenn der Typ sich aus den übergebenen Werten erschließen lässt). Z.B. bei Linq

var numbers = new[] { 3, 1, 2 };
var orderedNumbers = numbers.OrderBy( number => number );
var firstNumber = orderedNumbers.First( );

statt

int[] numbers = new int[] { 3, 1, 2 };
IOrderedEnumerable<int> orderedNumbers = numbers.OrderBy<int, int>( ( int number ) => number );
int firstNumber = orderedNumbers.First<int>( );

Das Beispiel ist zwar unnötig, stell das aber mal ohne zu Fluchen auf einen anderen Typ (z.B. decimal) um ;)

var numbers = new[] { 3m, 1m, 2m };
var orderedNumbers = numbers.OrderBy( number => number );
var firstNumber = orderedNumbers.First( );

statt

decimal[] numbers = new decimal[] { 3m, 1m, 2m };
IOrderedEnumerable<decimal> orderedNumbers = numbers.OrderBy<decimal, decimal>( ( decimal number ) => number );
decimal firstNumber = orderedNumbers.First<decimal>( );

Guck Dir mal Alles var - oder nicht? an ...

var erspart unter gewissen Umständen immensen Tippaufwand:

var memberAttr = reflectionProvider.GetSingleAttributeOrDefault<SerializationAttribute>(memberInfo);

Ich möchte es direkt ohne Intellisense den Typ sehen, daher verwende ich var immer wenn ich den Typ direkt auf der rechten Seite vom = sehe:

var p1 = new Point2d(); // OK für mich
var p2 = GetPoint(); // nicht OK für micht, da ich den Typ nicht direkt sehe
Point3d p3 = GetPoint(); // daher so, denn jetzt sehe ich den Typ direkt

Kurze Nachtrag. Bei LINQ ist es auf Grund der anonymen Datentypen recht nett. Dennoch versuche ich auch dort wenn es einen expliziten Typ gibt diesen zu nutzen, damit man direkt sieht was aus dem Query kommt

Hier stand Unsinn, sorry. Danke ffordermaier!