ich bin recht neu mit C# unterwegs und habe in vielen Codebeispielen gesehen, dass Variablen als var deklariert werden. Was var bedeutet, habe ich herausgefunden. Ich frage mich nur, warum in vielen Codebeispielen (z. B. bei dotnetpro) so gut wie jede Variable als var deklariert wird. Gibt es dafür gute Gründe oder auch Gründe die dagegen sprechen?
Diese Unart fällt mir auch oft auf, wenn ich C# Quelltexte durchlese. Die späte Bindung mag natürlich auch ihre Vorteile haben, ich bevorzuge allerdings die frühe Bindung (schon alleine, weil ich VB bevorzuge, ein Dim x As Object liest sich einfach beknackt ;-) ).
var hat nichts mit früher oder später Bindung zu tun. var ist immer dann zulässig, wenn der Compiler den Typ ableiten kann. Damit steht der Typ, der sich hinter einem var verbirgt immer zur Compilezeit fest.
Es lässt sich aber am Ehesten mit früher/später Bindung vergleichen. Anders ausgedrückt: ich mache oder du machst. Und ich bevorzuge, das selbst festzulegen.
Der Unterschied ist, dass in Deinem VB-Beispiel x as StringBuilder definiert ist. Dein C#-Beispiel heißt in VB übersetzt eher Dim x = New StringBuilder() oder Dim x As Object = New StringBuilder()
Natürlich funktioniert Dim x as new StringBuilder denn es ist eine Kurzform von Dim x as StringBuilder = new StringBuilder oder auch Dim x as StringBuilder x = new StringBuilder In dem Thread geht es aber, soweit ich die ursprüngliche Frage verstanden habe, eher darum, warum man in C# so gerne Variablen implizit definiert. Meine Aussage ist, dass ich (in VB) die explizite Version bevorzuge.
Dann schreib doch nicht, dass es für "as Object" steht, dem ist nicht so. Ich denke viele VB6ler wird das an Variant erinnern, und der Datentyp war damals schon ein No-go in den meisten Fällen. Das eine hat mit dem Anderen aber nichts zu tun.
"var x = new StringBuilder();" und "Dim x as new StringBuilder()" sind beides so genannte "syntactical sugar". Die MSIL-Spezifikation kennt beide Varianten nicht. ("var" übrigens auch nicht). Es ist beides also nur eine vereinfachte Schreibweise. Der Compilier macht entsprechend "Dim x as StringBuilder = new StringBuilder()" bzw. "StringBuilder x = new StringBuilder();" daraus.
@Jens: doch, es steht für Object (ehemals Variant, stimmt). Du kannst den Test selbst machen, indem Du in einem VB-Projekt Option Strict auf off stehen lässt. Schreibst Du im Code dann die Zeile Dim x = New StringBuilder bekommst Du im Fehler/Warnfenster angezeigt: Variablendeklaration ohne As-Klausel. Typ "Object" wird angenommen.
@Floyd: wir sind ja doch auf einer Wellenlänge ;-)
In VB6 waren Object und Variant m.E. nicht dasselbe. Zumindest gab es dort beide Typen.
Und bei "Object" funktioniert IntelliSense nicht. Von daher bin ich mir sicher, das var x = new StringBuilder() im IL-Code wirklich als StringBuilder x = new StringBuilder übersetzt wird. Mit Object wird das nicht funktionieren. Ich beziehe mich da jetzt ausschließlich auf C#. Für VB.net sehe ich absolut keinen Verwendungszweck mehr, und das als alter VB6ler.
"Variablen, die im Methodenbereich deklariert werden, können ab Visual C# 3.0 den impliziten Typ var aufweisen. Eine implizit typisierte lokale Variable ist stark typisiert, so als hätten Sie den Typ selbst deklariert. In diesem Fall hat jedoch der Compiler den Typ bestimmt."
"Das var-Schlüsselwort weist den Compiler an, den Typ der Variable aus dem Ausdruck an der rechten Seite der Initialisierungsanweisung abzuleiten. [...] Beachten Sie, dass das var-Schlüsselwort nicht für "variant" steht und damit nicht festgelegt wird, dass die Variable lose typisiert oder spät gebunden ist. Es bedeutet nur, dass der Compiler den am besten geeigneten Typ bestimmt und zuweist."
Jetzt dürfen wir nicht die Unterschiede zwischen C# und VB verwechseln! Ein "Object" kann eben alles sein (ein Dim x As Variant ändert die IDE übrigens kommentarlos direkt in Dim x As Object). In C# habe ich mich nie richtig "verlieben" können (liegt wahrscheinlich auch daran, dass viel nur mit var deklariert wird). Die Zitate aus der MSDN sind interessant (danke dafür!), aber dort zitierst Du selbst, dass var eine impliziter Typ ist ;-)
@muffi 1. In vb.net gibt es keinen Datentyp "Variant" mehr. Den gab es nur in VB6. 2. In vb.Net gilt: Object != Dim/Var. 3. Ich hab mir eben eine Konsolenanwendung erstellt und zwei StringBuilder erstellt. Einmal mit Dim/Var und einem mit "as Object". Die Object-Deklaration scheitert natürlich am Intellisense. Das ganze kompiliert und mit IL-Spy angeschaut.
object x = new StringBuilder(); StringBuilder x2 = new StringBuilder(); x2.Append("Deklaration mit 'var'"); NewLateBinding.LateCall(x, null, "Append", new object[] { "Deklaration mit 'object'" }, null, null, null, true);
@Jens: zu 1 habe ich ja schon geschrieben, dass die IDE das selbständig und ohne Kommentar abändert. Zum Rest: bestätigt nur meine Abneigung gegenüber implizite Deklaration (in VB!) :-) Dass es bei C# anders ist, habe ich ja jetzt gelernt - meine Abneigung, var zu lesen/benutzen, verändert das allerdings nicht. Ein "int y;" ist einfach schöner als ein "var z = new int();" finde ich. Deinen Test habe ich mit ILSpy übrigens auch nochmal nachvollzogen, in der VB-Syntax schaut das erwartungsgemäß genauso aus. Und dass var x = new StringBuilder(); funktioniert, sieht man auch beim Decompilieren.
@Muffi: Darfst ja auch gerne anderer Meinung sein. In vb.net würde ich den Var-Ersatz auch meiden. In C# nicht. Einfach aus dem Grund, das in VB(6) eine Deklaration ohne Angabe des Datentyps immer für Variant stand. Und Variant ist CodeSmell.
In C# sehe ich aber klar den Datentyp "var". Ich weiss zwar, das es sich in vb.net anders verhält als in VB6 aber 10 Jahre legt man nicht einfach so vom Bauchgefühl ad acta. Für mich ein Grund mehr vb.net zu meiden.
ich kann deiner Antwort in der verlinkten Diskussion nur beipflichten. Auch ich verwende var in der Regel nur dann, wenn klar ersichtlich ist welchen Typ der Compiler ableitet und das auch nur dann, wenn es sich nicht um einen eingebauten Typ wie int, string oder double handelt.
In der heranwachsenden Generation von Programmierern ist C# und .net ganz einfach uncool weil das alles vom ganz bösen Monster Microsoft kommt. Da sind dann andere Sprachen wo man sich nicht oder nur wenig um die Typen der Variablen Gedanken machen muss wesentlich hypper. Da kommt es dann schon ganz cool rüber, wenn man das var öfter benutzt, das dann den Anschein erweckt, dass man C# mit schwacher Typisierung benutzt.
In C# kann man sehr schnell sehr einfach lesbaren Quellcode erzeugen, in dem auch ein nicht in C# bewanderter Programmierer ganz schnell erkennen kann, was dieser Code machen soll. Das hat natürlich den Nachteil, dass der C#-Programmierer von seiner Intelligenz geringer geschätzt wird, weil der da so einfach unkomplizierten, leicht versteh baren Code erstellt hat. Viele kryptische vars im Quellcode veranlasst dann natürlich den, der nicht diese "Eigenheit" in C# kennt, vollends den der das Programmiert hat, als Halbgott der C#-Programmierung erscheinen.
Eigentlich stellt das var gerade für Programmieranfänger und Außenstehende eine Verständnis-Hürde von Quellcode dar, die eigentlich nicht sein müsste. Meiner Meinung nach müsste Quellcode ohne dem Spezialwissens um Compiler-Tricks sprechend und selbsterklärend sein.
Es ist dann halt irgendwann ganz cool geworden, möglichst viele vars zu verwenden. Im Programmier-Unterricht an Schulen oder in Anfänger-Bücher übers C#-Programmieren kommt das var so gut wie nie vor oder wird irgendwie ganz am Ende nur ganz kurz erklärt. Das ist dann auch, warum so viele Programmieranfänger über Beispielcode stolpern und diesen nicht anständig verstehen.
danke für eure Antworten! Wenn ich die verschiedenen Meinungen zusammenfasse, komme ich zu dem Schluss, dass es wohl Geschmackssache bzw. Gewohnheitssache ist. An manchen Stellen wird der Code übersichtlicher, vor allem, wenn es um Typen mit meterlangen Bezeichnern geht, an anderen Stellen handelt man sich unter Umständen Probleme ein. Wirklich gute Argumente, warum man möglichst nur noch var verwenden sollte (außer wenn es um Linq geht), scheint es nicht zu geben.
Ich verwende var ganz gerne, arbeite auch viel mit Linq. Mir vereinfacht var das Lesen des Codes, meistens ist für mich das Wissen um welchen Typ es sich jetzt handelt eher sekundär. Selten muss ich auf eine explizite Deklaration zurückgreifen (dort wo man z.B. ein out verwendet, was ja auch eher selten vorkommt).
Im Großen und Ganzen stimme ich mit Eric Lipperts Zusammenfassung aus obigem Link überein, besonders auf sprechende Variablennamen (usw...) kann nicht genug Wert gelegt werden.
