| 

.NET C# Java Javascript Exception

5
Hallo,

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?

Danke im Voraus für Antworten!
Helga
News:
29.01.2014
helga 31 3
5 Antworten
1
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 ;-) ).
29.01.2014
muffi 1,4k 1 9
2
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.
ffordermaier 29.01.2014
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.
muffi 29.01.2014
Wo siehst du denn einen Unterschied zwischen zwischen
Dim x as new StringBuilder()
und
var x = new StringBuilder();
??
Floyd 30.01.2014
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()

muffi 30.01.2014
Nein: Dim x as new StringBuilder() funktioniert in VB.Net!
Floyd 30.01.2014
Der Kompiler leitet den Typen korrekt her. Genauso wie im C#.
Floyd 30.01.2014
Object Creation Changes in Visual Basic: http://msdn.microsoft.com/en-us/library/Aa903373
Floyd 30.01.2014
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.
muffi 30.01.2014
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.
Jens Duczmal 30.01.2014
"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.
Floyd 30.01.2014
@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 ;-)
muffi 30.01.2014
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.

Mit Syntactic sugar hat Floyd recht.
Jens Duczmal 30.01.2014
var != object != variant !!!!!

Was du meinst ist "dynamic".

Aus dem MSDN:

"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."

http://msdn.microsoft.com/de-de/library/bb383973.aspx
Floyd 30.01.2014
sowie:

"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."

http://msdn.microsoft.com/de-de/library/bb384061.aspx
Floyd 30.01.2014
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 30.01.2014
@Floyd, meinst Du jetzt mich oder muffi.
Ich weiss dass. Mir musst Du das nicht sagen :)
Jens Duczmal 30.01.2014
@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 Duczmal 30.01.2014
@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 30.01.2014
MailMessage ms = new MailMessage();
StmpServer smtp = new SmtpServer();
StringBuilder sb = new StringBuilder();

vs.

var ms = new MailMessage();
var smtp = new SmtpServer();
var sb = new StringBuilder();

ich finde letzteres lässt sich besser lesen und sieht übersichtlicher aus. (mein persönliches empfinden)
Floyd 30.01.2014
Was gar nicht geht (man aber sehr oft liest, auch in der Java-Welt):
int Int = new int();
muffi 30.01.2014
int i = new Int32();
Floyd 30.01.2014
oder sogar:

int i = new int();
Floyd 30.01.2014
@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.
Jens Duczmal 30.01.2014
1
Ich hoffe nur, Helga hat mitgelesen, denn der Diskussionsverlauf hat eigentlich die Antwort auf die Frage ergeben.
muffi 30.01.2014
0
Wir hatten hier schon mal eine ausführliche und interessante Diskussion darüber.
Bei weiteren Fragen, melde Dich einfach nochmal.
29.01.2014
ffordermaier 8,4k 3 9
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.
luedi 30.01.2014
0
Ich hab da auch so meine Theorien darüber.

  • 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.
30.01.2014
Stelzi79 44 1
0
Hallo,

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.

Danke nochmal,
Helga
30.01.2014
helga 31 3
0
Gute Zusammenfassung!

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.
31.01.2014
cybere 353 9

Stelle deine .net-Frage jetzt!