13 fest verankerte var-Mythen und deren Auswirkungen auf Code-Qualität

von Sergej Kukshaus vor 6 monaten

Bin ich allein?

In den letzten Tagen habe ich mir diese Frage tatsächlich mal öfter gestellt.

Nein, so schlimm wie du denkst, ist es mit mir noch lange nicht 🙂

Was ich meine, ist eigentlich etwas ganz banales. Und zwar so banal, dass es sich eigentlich gar nicht lohnt darüber nachzudenken.

Trotzdem entfacht es immer eine Grundsatzdiskussion.

Die Frage ist:

Warum wird so häufig var verwendet?

Wenn ich aktuelle Bücher und Tutorials ansehe, sehe ich immer wieder das Schlüsselwort var. Auch unter meinen Kollegen hat es sich verbreitet wie ein Virus.

Es ist sogar mal so ausgeartet, dass mal ein Kollege in einer Legacy-Anwendung alle Typdefinitionen durch var ersetzt hat.

Und das nicht händisch, nein. Per Code-Bereiniger.

Und glaub mir, damit hat er dem Quellcode keinen Gefallen getan.

Die Ursache allen Übels

Als Microsoft das Schlüsselwort var erstmals mit C# 3.0 eingeführt hat, wurde in der Dokumentation folgendes geschrieben:

Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important.

C# Coding Conventions

Ich lese hier raus. Du kannst var verwenden:

  • Falls aus der Anweisung nicht herausgeht, um welchen Typen es sich handelt.
  • Falls der Datentyp sich aus dem Kontext ergibt.

Was ich nicht herauslese, ist:

  • Du musst immer var verwenden.

Ilya Ryzhenkov von JetBrains hat die vermeidlichen Vorteile bei der Verwendung von var genannt.

JetBrains hat im ReSharper standardmäßig eine Regelung hinterlegt, dass überall var verwendet werden soll. Tut man dies nicht, wird einem eine Warnung angezeigt.

Der unwissende Programmierer korrigiert dies natürlich, ohne darüber nachzudenken. Falls doch, wird JetBrains befragt. Und was sagt JetBrains an dieser Stelle? Es sei besserer Programmierstil.

Okay, wenn JetBrains und Microsoft das sagen, muss doch schon was dran sein, oder? Und ZACK! Es wird nur noch var verwendet. Überall.

Doch bewerten wir mal alle Argumente beider Lager rein subjektiv.

Den objektiv geht schnell: var ist das schlimmste, was C# hätte je passieren können.

Mythos 1: var ist für anonyme Typen zwingend erforderlich

Zunägst einmal: „Was ist ein anonymer Typ“?

In C# kann man ein Objekt definieren, ohne explizit ein Typ dafür zu verwenden.

var person = new {
    Name = "Sergej",
    Alter = 35
};

Anschließend haben wir ein Objekt, welches einen Namen und das Alter hällt.

Soweit so gut. Die Frage ist jetzt nur, wofür benötigt man sowas eigentlich?

Anonyme Typen werden bevorzugt mit der Select()-Methode aus LINQ verwendet.

Jedoch verwende ich es auch mal gerne, um diverse APIs zu erstellen. So benötige ich keine zusätzliche Modellklasse, die sowieso nur ein einziges Mal verwendet wird. An dieser Stelle mag ich es lieber einfach.

Kann man anonyme Klassen ohne var erstellen? Nein! Hierfür benötigt man zwingend das var.

In den meisten Fällen kann man jedoch direkt auf die anonymen Klassen (und auf das var) verzichten, indem man sich eine neue Klasse erstellt.

Mythos 2: var fördert eine bessere Namensgebung

Das ist eins der Lieblingsargumente der var Befürworter.

Angeblich haben Entwickler, nur weil var verwendet wird, sofort eine Erleuchtung in Sachen Namensgebung.

Da werden auf einmal selbsterklärende Variablenbezeichnungen zugesprochen, die auf den ersten Blick die Welt erklären.

Nur weil man var verwendet, schreibt man auf einmal:

var productName = _products.GetProductNameById(42);

anstelle von

string product = _products.GetProductNameById(42);

Und wie sieht es in der Realität aus?

var product = _products.GetById(42);

„Das hat er sich doch ausgedacht“ magst du dir denken.

Dann schau mal hier, hier, hier, hier und hier. Und das ist nur ein kleiner Auszug aus github.

Besonders gut hat mir das hier gefallen:

var dict = context.Context.References;

Und wie sieht hingegen guter Code aus?

Schau dich doch mal in diesem Repository um. Hier sehe ich kaum vars. Stattdessen überall explizite Verwendung der Typen.

Und das Repository ist nicht von irgendeinem dahergelaufenen Möchtegern-Guru (so wie mir), sondern von einem Microsoft-Team. Also denselben Leuten, die gesagt haben: „Use [var] when the type of the variable is obvious from the right side„.

Mein Mathelehrer hat immer gesagt:

Eine These gilt so lange, bis sie das erste Mal widerlegt wurde.

Herr K. aus L.

Mythos 3: var entscheidet sich für den besten Datentyp

Und das sowohl bei der Initialisierung, als auch bei Rückgabewerten.

Wenn eine Methode beispielsweise als Rückgabewert PommesRotWeiss hat, dann ist der Typ auch PrommesRotWeiss.

Viele Entwickler sagen dann an der Stelle, dass es die nicht interessiert welcher Datentyp da zurückkommt. Hauptsache es steht in der Methode.

Schauen wir noch einmal das Beispiel von oben an:

var product = _products.GetById(42);

Was zur Hölle ist product? Als Erstes würde man denken, es wäre ein Datenmodell (POCO, DTO, whatever). Es könnte aber auch ein string (Name) oder sonst noch was sein.

Und wozu brauchen wir diese Information? Na ganz einfach, für den weiteren Verlauf des Quellcodes.

Ich möchte nämlich ganz genau wissen, was ich mit diesem Objekt alles anfangen kann. Ein string muss ich anders behandeln als ein Datenmodell.

Jedoch kann es auch passieren, dass sich der Compiler mal für den falschen Datentypen entscheidet:

static void Main()
{
    IFoo foo1 = new Foo();
    DoIt(foo1);

    var foo2 = new Foo();
    DoIt(foo2);
}

static void DoIt(IFoo foo)
{
    Console.WriteLine(@"Hello World");
}
static void DoIt(Foo foo)
{
    Console.WriteLine(@"format C:\");
}

Während bei foo1 noch alles in Ordnung ist, passiert bei foo2 schon etwas ganz anderes.

Unwahrscheinlich, dass jemand, jemals sowas schreibt? Möglich. Doch was ist damit?

var foobar = new Foobar();
IFoo foo = new Foobar();
IBar bar = new Foobar();

foo.DoIt();
bar.DoIt();
foobar.DoIt();

Auf den ersten Blick, würde man denken, dass hier immer dieselbe Ausgabe erfolgt.

Wenn man sich die Foobar-Klasse jedoch näher anschaut:

class Foobar : IFoobar
{
    public void DoIt()
    {
        Console.WriteLine("DoIt with foobar");
    }
    void IFoo.DoIt()
    {
        Console.WriteLine("DoIt with foo");
    }
    void IBar.DoIt()
    {
        Console.WriteLine("DoIt with foo");
    }
}

Wird man feststellen, dass man drei unterschiedliche verhalten hätte.

Dieser Fall ist jedoch schon möglicher als der obere.

Mythos 4: var reduziert „Code-Rauschen“

Gemeint ist damit, dass die Variablen nicht in einer Spalte beginnen. Man kann also nicht das var einfach „ausblenden“ und nur noch die Variablennamen lesen. Nein, stattdessen muss man die ganze Zeile lesen.

Ganz ehrlich, wenn man denn einen passenden Namen gefunden hat, der genau das beschreibt was die Variable beinhaltet (in den meisten Fällen ist dies nicht der Fall), dann sind die Gleichheitszeichen sowieso immer an unterschiedlichen Stellen. Und man muss mit den Augen von links nach rechts springen.

Es gibt auch nicht häufig den Fall, an dem man 10 Variablen untereinander schreiben muss, sodass das so sehr ins Gewicht fallen würde.

Schlimmer finde ich hingegen Zeilen, die viel zu lang sind. Optimal sind 80 Zeichen. 120 Zeichen sollte man eigentlich nie überschreiten.

Und dann gibt es noch Entwickler, die folgendes behaupten:

In the ideal C# world, we would not have to put any words in front of a variable name at all.

Michael Brennan

Brennan schreibt weiter (und reagiert auf Gegenargumente):

“It reduces clarity” – How?  By removing the noise in front of a variable name, your brain has only one thing to focus on:  the variable name.  It increases clarity.

Ich habe mal vor einiger Zeit folgenden Quellcode gesehen:

var repository = new Repository();
var products = repository.GetProducts();

// viel quellcode

foreach (var p in products)
{
    // etwas quellcode

    var product = repository.GetProduct(p);

    // anderer quellcode
}

Ohne Witz, ich habe mir das jetzt nicht ausgedacht.

Beim Debugen, habe ich mich gewundert, warum der Quellcode nicht funktioniert hat. Nach etwa 10 Minuten, habe ich dann endlich mal herausgefunden, dass es sich hier um sehr unglücklich gewählte Namensgebung handelte. Und das gleich an mehrere Stellen.

Da es dazwischen noch anderen Quellcode gab, war es für mich nicht direkt ersichtlich wie die Typen zusammenhängen bzw. das sie überhaupt zusammenhängen.

Und wie habe ich das herausgefunden? Indem ich überall das var durch den expliziten Typen ersetzt habe.

In diesem Fall hat es mir tatsächlich Übersichtlichkeit genommen. Würde zu allem Überfluss noch das var fehlen, würde ich noch nicht einmal darauf kommen, dass es sich um eine neue Variable handelt.

Fazit: Besonders in Legacy-Code, langen Methoden oder einer hohen Zyklomatischen Komplexität, ist die Verwendung von var tödlich.

Mythos 5: Man benötigt keine Using-Direktive

Wenn man an den Anfang einer Quellcode-Datei schaut, sieht man da ein Block mit usings.

Ich finde es schon witzig, dass genau dieses „Mega-Argument“ von einem JetBrains Mitarbeiter kommt.

Bei ReSharper (und mittlerweile auch bei Visual Studio nativ) ist es genau ein Tastendruck und die Using-Direktive ist automatisch generiert.

Und ganz ehrlich. Stört es dich wirklich, wenn die ersten 20 Zeilen Quellcode ausschließlich usings beinhaltet? Also mich, nicht.

Mythos 6: var ist nicht typsicher

Wer das denkt, der hat zu viel JavaScript oder PHP programmiert.

Nehmen wir mal diesen JavaScript-Code:

var numberOfDataSets = "18"; // Könnte so z.B. aus einer API kommen
var offset = 2;
var numberOfTotalResult = numberOfDataSets + offset;

Sowohl in C# als auch in JavaScript ist das gültiger Quellcode.

In beiden Sprachen kommt jeweils 182 als Ergebnis raus. Oder hast du etwas anderes erwartet?

Schauen wir uns mal dieses Beispiel an:

var alter = "34";
alter = 35;

Dieser Quellcode ist unter C# so nicht kompilierbar, lässt sich jedoch unter JavaScript ausführen und bringt das gewünschte Ergebnis und Verhalten.

Bei der Instantiierung wird das Objekt ‚alter‚ vom Typ string erzeugt. Versucht man jetzt einen anderen Typen (in diesen Fall int) zuzuweisen, wird dies fehlschlagen.

Und jetzt kommt mein absolutes Lieblingsbeispiel:

var x = 5;
var y = 2;
var z = x / y;

Und was ist hier das Ergebnis?

javascript vs csharp

Was haben diese drei Beispiele gemeinsam?

Das Fehlverhalten in JavaScript tritt nur auf, weil es sich nicht um eine stark typisierte Sprache handelt.

Wenn man jetzt allerdings nicht mehr in Typen denkt, sondern nur noch in Werten, dann kann man schon mal falsch interpretieren. Schließlich hat man in der Schule gelernt, dass 5 durch 2 nun einmal 2.5 sind. Datentypen bringt man schließlich nicht in der dritten Klasse bei.

Fakt ist: C# ist und bleibt typsicher.

Wenn man jedoch übermäßig viel var verwendet, besteht die Gefahr, dass man nicht mehr weiß um welche Datentypen es sich handelt. Weil es einen nicht mehr interessiert und man auf einmal anfängt nicht typisiert zu denken.

Mythos 7: var ist ein Performance-Killer

Wow.

Wer das tatsächlich behauptet, der hat das Prinzip von var nicht verstanden.

Der C# Compiler optimiert bei der Kompilierung den Quellcode nach gewissen Richtlinien.

Jedes var wird nach dem Kompilieren also voll ausgeschrieben als Datentyp im IL-Code abgebildet. Faktisch macht es genau 0 Unterschied, ob man da jetzt den genauen Datentypen hinschreibt oder nur var.

Wenn überhaupt, dann dauert das Kompilieren einer Applikation, die mit var überflutet ist, etwas länger. Ich könnte mir aber vorstellen, dass der Unterschied im unteren Promillebereich liegt.

Mythos 8: Alle, die var verwenden, sind faul.

Ich bin ehrlich.

Wenn ich eine neue variable benötige, sieht bei mir der Code häufig zu Begin so aus:

var nameDerVariable = 

Anschließend schreibe ich dann das hin, was ich möchte. Und wenn sich aus der rechten Seite, nicht der Datentyp ergibt, lasse ich ReSharper das var in expliziten Datentypen konvertieren.

Japsolut. An dieser Stelle bin ich faul und mache mir die Eigenschaften von var und ReSharper zu eigen.

Doch halt, wenn man schon bei der Vergabe des Datentyps faul ist, wie zur Hölle, traut man sich zu behaupten, dass man dadurch bessere Namensgebung erreicht (s.o. Mythos 2)?

var income = account.GetTotalIncomeOfTheLastYear();

Was meinst du?

  • Ist es der Datentyp bei der genannten Methode wichtig?
  • Ist der gewählte Variablenname aussagekräftig?
  • Was denkst du, welcher Datentyp ist hier gegeben?

Gerne kannst du mir deine Antworten unten in die Kommentare schreiben.

Fazit: Meiner Meinung nach, sind die var-Verwender, faul.

Mythos 9: Wer kein var verwendet, kennt seine IDE nicht.

Zu dieser sehr gewagten These gibt es gleich mehrere Aussagen, die jedoch alle dasselbe aussagen.

Wenn dich doch der Datentyp interessiert, fahre mit der Maus über die Variable und dann siehst du es.

Ich bin Softwareentwickler, kein Grafiker. Ich arbeite mit der Tastatur und nehme meine Maus nur selten in die Hand.

Mit der Tastatur bin ich deutlich schneller.

Das ist auch der Grund, warum ich aus Visual Studio meine Applikationen mit [F5] starte und nicht über den „grünen Start-Pfeil“ oder gar über „Menü > Debuggen > Debuggen starten“.

Ich vermute, dass jene Personen, noch nicht einmal ein Bruchteil aller Visual-Studio-Hotkeys kennen. Einfach aus dem Grund, weil man zu oft zur Maus greift.

Wenn wir anfangen mit Notepad zu entwickeln, dann höre ich auf var zu verwenden.

Wenn jedes Programm auf der Welt, welches C#-Code anzeigen kann, das var auflösen kann, dann fange ich vielleicht an, var zu akzeptieren.

Ganz ehrlich, was ist das für ein Argument? Ich lese oft den Quellcode über die Quellcode-Verwaltung. Sei es nun GitHub oder einen Git-Client.

Aber auch in Visual Studio möchte ich nicht jedes Mal mit der Maus über die Variable gleiten, nur um herauszufinden, dass sich die Variable, von der ich dachte, es wäre ein double sich auf einmal als ein int herausstellt.

Ich möchte Klarheit. Auf den ersten Blick. Geht es dir da etwa anders?

Fazit: Das Argument ist kein Argument und rechtfertigt noch lange nicht die Verwendung von var.

Mythos 10: var erlaubt keine null Initialisierungen

Und das aus einem verdammt guten Grund.

var person = null;

… ist natürlich komplett ungültiger Quellcode. Woher soll auch bitte der Compiler wissen, welchen Datentypen man hier zuweisen möchte? Schließlich gibt es keinen Datentypen null. Und null kann auch nicht implizit in einen bestimmten Typ werden.

Um jedoch trotzdem beim var zu bleiben, haben sich solche Entwickler etwas [Sarkasmus]grandioses[/Sarkasmus] ausgedacht:

var person = (Person)null;
var person = default(Person);

Warum schreibt man nicht einfach nur?

Person person = null;

Auch gut ist natürlich folgendes Beispiel:

var foo = (int?)42;
int? bar = 42;

Sei ehrlich, welche der genannten Zeilen Code findest du persönlich lesbarer? Schreib es doch bitte unten in die Kommentare. Das würde mich brennend interessieren. Und vor allem Dingen das „warum“.

Mythos 11: Ungarische Notation hat man ja auch abgeschafft

Kurz: Ja, hat man.

Zunächst einmal, was ist die ungarische Notation? Kurz gesagt: Der Datentyp, steht explizit im Variablennamen:

string strLength = "42m";
int iLength = 42;
List<Person> personList = new List<Person>();
Button btnName = new Button();
Label lblName = new Label();

Warum hat man die abgeschafft? Weil sich der Datentyp mal ändern kann und man dann immer die Variablennamen ebenso anpassen muss.

In meinem Unternehmen, haben wir eine Legacy Anwendung, diese wurde noch mit WinForms und der ungarischen Notation entwickelt. Und ganz ehrlich: Gerade bei dieser „Architektur“ ist die ungarische Notation hilfreich.

Ich verstehe ja, dass man bei einer sehr guten und unmissverständlichen Namensgebung auf explizite Typdefinitionen verzichten kann.

Wie könnte man jedoch diese Zeile Quellcode ändern, sodass man hier var verwenden kann?

Dictionary<string, Person> people = repo.GetAllPeopleGroupedByDepartment();

Ich finde, sobald es um Dictionaries geht, sagt der Datentyp mehr aus als die beste Variablenbezeichnung. Findest du nicht auch?

Mythos 12: var erleichtert Refactoring

Im Laufe der Zeit ändern sich schon einmal die Anforderungen.

Da muss mal ein Rückgabewert geändert werden. Hier muss mal eine Methode umbenannt werden und an einer anderen Stelle kommt mal ein Interface hinzu.

Damit man nicht überall im Quellcode ebenfalls die Datentypen ändern muss verwendet man stattdessen var.

So jedenfalls der faule Entwickler (siehe Mythos 8).

Der smarte Entwickler hingegen geht her und überprüft seinen Quellcode noch einmal, ob alles noch so passt, wie es denn gewollt ist.

  • Stimmt noch die Namensgebung?
  • Ist der Code immer noch lesbar?
  • Hat man vielleicht ein Fehler eingebaut?

Eine Klasse oder auch eine Methode umzubenennen, kann man auch ganz schnell mit dem Refactoring-Feature von Visual Studio oder ReSharper. Das geht ganz innerhalb von ein paar Sekunden.

Wird die Klasse jedoch in einer anderen Komponente verwendet, springt natürlich das Refactoring nicht an. Würde man in der externen Komponente var verwenden, bräuchte man den Quellcode nicht mehr zu ändern.

So die Aussage der var-Befürworter.

Es gibt da nur ein Problem: Das Verändern der Methodensignaturen, verletzt das Open-Closed-Prinzip. Somit sollte es nicht das Ziel sein bestehende Funktionalität so zu verändern, dass andere Komponenten damit nicht mehr zurechtkommen.

Ich berufe mich hier ganz gerne mal auf die „Andreas-Regel“

Mythos 13: Wenn ich var verwende, wird mein Code verständlicher

Auf stackoverflow habe ich einen sehr schönen Beitrag gefunden, welches ich hier aufgreifen möchte.

Nehmen wir mal einen einfachen deuschen Satz:

Kevin begrüßt Marvin. Er mag ihn nicht, also dreht er sich um und geht.

In diesem einfachen Beispiel sind Kevin und Marvin Datentypen und die Personalpronomen (er, ihn) stehen repräsentativ für var.

Allein aus dieser Aussage geht nicht hervor, wer weggegangen ist und wer den jeweils anderen nicht mag. Um hier Klarheit zu verschaffen, müssen wir präziser werden.

Kevin begrüßt Marvin. Marvin mag Kevin nicht, also dreht er sich um und geht.

Jetzt ist schon klarer, wer den jeweils anderen nicht mag. Wenn man ein wenig nachdenkt, könnte man auch darauf kommen, dass Marvin weggeht.

Aber warum sagen wir das nicht sofort?

Kevin begrüßt Marvin. Marvin mag Kevin nicht, also dreht Marvin sich um und geht.

Und jetzt ist es komplett unmissverständlich ausgedrückt. Findest du nicht auch?

Wenn jedoch aus der Aussage unmissverständlich hervorgeht, wer oder was gemeint ist, dann kann man auch das var (oder die Personalpronomen) verwenden.

Anna mag Bücher. Also geht Anna in die Bibliothek, nimmt Annas Lieblingsbuch und liest es in Ruhe.

Ich glaube, mir wird jeder zustimmen, dass diese Aussage keiner treffen wird.

Folgende Aussage sagt genau dasselbe aus:

Anna mag Bücher. Also geht sie in die Bibliothek, nimmt ihr Lieblingsbuch und liest es in Ruhe.

Ich sage nicht ohne Grund immer:

Guter Quellcode, liest sich wie ein gutes Buch.

Sergej Kukshaus

Wann ich var verwende

Ja, ich verwende auch var. Allerdings ist das nicht allzu häufig. Jedenfalls nicht so häufig wie es manche andere Entwickler tun.

// wenn ich eine neue Instanz eines Objektes bilde
var persons = new List<Person>();

// wenn ich einen generischen Datentypen verwende
var manager = kernel.Get<Manager>();

// wenn ich mit annonymen Datentypen arbeite (sehr selten)
var tmp = new { foo = "bar" };

Kurz gesagt, ich verwende var immer dann, wenn ich den Datentypen der Variable in der Zeile sehe oder ich keine andere Möglichkeit habe, weil es keinen Datentypen gibt.

Ein kleiner Denkanstoß zum Schluss

Warum ist folgender Quellcode nicht nur nicht möglich, sondern auch „tödlich“ wenn es denn möglich wäre?

class Context
{
    private var _data;

    public Context()
    {
        _data = new List();
    }
    public void Add(var dataSet)
    {
        _data.Add(dataSet);
    }
    public var Get()
    {
        return _data;
    }
}

Wir müssten uns an dieser Stelle gar nicht mehr um Datentypen kümmern und alles wäre perfekt dynamisch.

Warum dürfen wir Entwickler auf Code-Ebene var verwenden, jedoch nicht auf Methoden- und Klassen-Ebene?

Fazit: var oder nicht var, das ist hier die Frage

Wahrscheinlich könnte ich hier noch unzählige, schwachsinniger Argumente gegen die Verwendung von var auflisten.

Stellt man jedoch die Vorteile und die Nachteile bei der Verwendung von var gegenüber, so überwiegen die Nachteile.

Jedoch bin ich nicht so stur. Wenn mir jemand das absolute Top-Argument für die var-Verwendung sagt, dann überlege ich es mir noch einmal.

Als Ausbilder, lege ich meinen Azubis nahe, auf das var zu verzichten und stattdessen immer den expliziten Typen zu verwenden.

Wenn die Auszubildenden während der Ausbildung doch mal auf das var stoßen, schauen sie es sich komisch an und finden das direkt verwirrend. Im Verlauf der Ausbildung steigt natürlich das Fachwissen, sodass sie sich selbst ein Urteil darüber bilden können.

Resultat bleibt immer dasselbe: Es wird kein var verwenden. Und zwar nicht, weil ich die Azubis dazu zwinge. Nein, weil sich die jungen Entwickler eigenständig so entschieden haben und es für schlecht, bzw. unübersichtlich befunden haben.

Noch interessanter sind Praktikanten. Junge Menschen, die noch nie programmiert haben.

Ohne überhaupt nur ein Wort darüber verloren zu haben, habe ich noch bei keinem einzigen jemals var im Quellcode gesehen. Und ja, ich lasse sie eigenständig eine Suchmaschine ihrer Wahl verwenden, um sich die Lösung eigenständig zu erarbeiten.

Update 9. Juni 2020

Mit diesem ursprünglichen Beitrag habe ich ja ein wenig die var Beführter herausgefordert mich von var zu überzeugen:

Jedoch bin ich nicht so stur. Wenn mir jemand das absolute Top-Argument für die var-Verwendung sagt, dann überlege ich es mir noch einmal.

Und was machen JetBrains daraus? Nimmt diese Herausforderung an und baut ein Feature in den ReSharper, welches mich tatsächlich überzeugt hat.

Ich habe ja bereits geschrieben, dass man var verwenden kann (und auch soll), falls der Datentyp innerhalb der aktuellen Zeile steht.

Und was soll ich sagen, JetBrains hat genau das implementiert.

Verwendet man jetzt das var, steht hinter dem Bezeichner der korrespondierende Datentyp. Und zwar immer, wenn der Bezeichner nicht eindeutig ist.

Selbst in einem Lamda-Ausdruck, bei dem viele Entwickler einfach nur „x“ schreiben (würg) steht jetzt der Datentyp.

Wenn man anhand des Namens den Datentyp bereits rauslesen kann, wird diese Anzeige weggelassen, so wie bei dem foreach zu sehen. Wählt man jedoch keine passende Bezeichnung, dann wird der Datentyp angezeigt.

Wie geil ist das den? 🙂

Auf der anderen Seite birgt das jetzt die Gefahr, dass man zwanghaft versuchen möchte diese Ansicht zu vermeiden, weil man der Meinung wäre, dass man gerade eine schlechte Namensgebung gewählt hat.

Dies sollte nicht der Fall sein. Stattdessen ist es ab jetzt gute Namensgebung wichtiger den je.

Abschließend möchte ich nur noch sagen, solltest du kein ReSharper verwenden, bitte halte immer noch Abstand von var. Andernfalls steht einer Verwendung von var nichts mehr im Wege.

Sei der erste und teile deine Meinung mit der Welt!
... und was meinst du dazu?
Deine E-Mail-Adresse wird nicht veröffentlicht.