Var Schluesselwort

Var Schluesselwort

Von Jan Suchotzki

Wenn ich bisher in einem Quellcode die Verwendung von var gesehen habe, dann konnte ich immer ein leichtes Unbehagen verspühren. Das liegt wohl daran, dass mir bisher noch nicht klar war, was die Verwendung des Schlüsselwortes bedeutet. Bisher hatte ich den Eindruck, dass damit die Typisierung aufgehoben wird. Aber:

Das var-Schlüsselwort weist den Compiler an, den Typ der Variable aus dem Ausdruck an der rechten Seite der Initialisierungsanweisung abzuleiten. – MSDN

Wie du siehst, geht es nicht darum, die Typisierung aufzuheben. Vielmehr überlässt du es dem Compiler den besten Typ auszuwählen. Dies ist ein klarer Unterschied zu beispielsweise JavaScript! Nun aber zu den Beispielen.

Gerade bei anonymen Typen und LINQ-Abfragen kommst du ohne var nicht zurecht. Ob du deren Einsatz brauchst oder für sinnvoll erachtest, bleibt dir überlassen. Hier Quellcode den ich in diesem Kontext interessant finde:

// mit var - ohne Wissen von LINQ und anonymen Typen kann ich nicht erklären
// wie genau die Abfrage funktioniert.
// Allerdings kann ich erahnen, dass Name und Alter aller Kunden abgefragt wird.
var query = from c in customers select new {c.Name, c.Age};

// eine Möglichkeit ohne var - hier kann ich weder sagen, was passiert, noch wie
// es passiert. Für mich die schlechtere Variante.
IEnumerable<NameAndAge> query 
      = Enumerable.Select<Customers, NameAndAge>(customers, NameAndAgeExtractor);

Einen weiteren vermeintlichen Vorteil zeigt folgendes Beispiel:

var resultat = apfel.VergleicheMit(birne);
Console.WriteLine("Apfel hat folgende Unterschiede zu Birne: " + resultat.ToString());

Wenn die Methode VergleicheMit ihren Rückgabewert ändert, z.B. durch ein Refactoring, brauchst du den aufrufenden Code nicht zu ändern. Für mich ist das kein gutes Beispiel für die Verwendung von var, weil ich es bevorzuge diese Stellen anzuschauen. Vielleicht macht die Ausgabe des neuen Rückgabetyps gar keinen Sinn mehr. Da finde ich es besser, dass der Compiler mir sagt, dass die Typen nicht zusammen passen und ich die Stellen von Hand ändere. Das ist natürlich zusätzlicher Aufwand.

Ein wichtiger Fall in dem die Verwendung von var Sinn macht, ist die Reduzierung von Redundanz. Schau dir folgendes Beispiel an:

//explizite Definition ohne var
Dictionary<string, List<decimal>> rabatteProKunde = new Dictionary<string, List<decimal>>();

//implizite Definition mit var
var rabatteProKunde = new Dictionary<string, List<decimal>>();

Die Version ohne var bringt keinerlei zusätzliche Information oder Nutzen. Also verwende ich zukünftig var in solchen Fällen. Mit Ausnahme von anonymen Typen und LINQ, scheint mir Lesbarkeit das entscheidende Kriterium für die Verwendung von var zu sein. Du kannst mit diesem Schlüsselwort die Lesbarkeit sowohl positiv wie auch negativ beeinflussen.

Jetzt erstmal viel Spaß beim reflektieren wie du var besser einsetzen kannst als bisher.

Jan

Merke

Die folgenden Punkte basieren auf dem hervorragenden Artikel von Eric Lippert:

  • Verwende var, wenn du anonyme Typen verwendest.
  • Vermeide Redundanz und verwende var, wenn der Typ offensichtlich von der Initialisierung ist.
  • Überlege ob du var verwendest, wenn der daraus entstehende Quellcode das “Was” in den Fokus setzt und das “Wie” verbirgt.
  • Verwende immer beschreibende Variablennamen, egal ob due var einsetzt oder nicht. zinssatz ist besser als dezimalWert.

Lernquiz

  • Legst du mit var eine nicht typisierte Variable an?
  • Wie wird der Datentyp für eine mit var definierte Variable ermittelt?
  • Welchen Einfluss hat var auf die Lesbarkeit des Quellcodes?
  • Gibt es Fälle in denen du var verwenden musst?

Am besten du schaust dir morgen und dann nochmal in ein paar Tagen die vorherigen Fragen an und beantwortest sie ohne den Text vorher gelesen zu haben.

Weitere Informationen

  • Zu diesem LernMoment gibt es keinen zusätzlichen Quellcode.
  • Eine Einführung und (teilweise etwas komische) Beispiele findest du bei MSDN
  • Eine super Erklärung, allerdings nur auf Englisch, gibt der Artikel von Eric Lippert.