c# - datentyp var

[pkranig2023]

Hallo,

 

ich habe mal was ganz interessantes entdeckt: den datentyp var.

er sucht ja automatisch damit den passsenden (int oder double, usw.) datenty?

also braucht man keine explizite und inplizite konvertierung mehr?

 

Ist das eine saubere programmierung?

 

edit: gerade probiert, parsen bei Usereingaben muss ich immer noch ?

 

mfg

[arlegermi]

Guck dir am besten mal die Dokumentation von Microsoft an. "var" ist ausschließlich Kurzschreibweise* für den eigentlichen Typen - da passiert nichts dynamisches zur Laufzeit. 

Über den Nutzen von "var" scheiden sich die Geister. Ich bin der Meinung, dass man es so oft wie möglich einsetzen sollte - so lange der Code damit lesbar bleibt. Andere meinen, dass man es der Verständlichkeit halber nur nutzen sollte, wenn es entweder 100% eindeutig ist oder keine andere Möglichkeit besteht.

 

* bzw. in einigen Fällen die einzige Möglichkeit, den Typ zu deklarieren (im Kontext von LINQ, wenn man anonyme Typen erzeugt)

Bearbeitet 20. November 2018 von arlegermi

[Whiz-zarD]

var ist kein Datentyp. var ist eine implizite Typendeklaration um obligatorischen Code zu sparen. Anstatt

TolleKlasse klasse = new TolleKlasse();

kannst du auch einfach

var klasse = new TolleKlasse();

schreiben. Der Datentyp ist zur Entwicklungszeit bekannt, also muss man auch den Datentyp explizit nicht angeben.

Dass var kein Datentyp ist, kannst du auch sehen, dass du var nicht als Methodenparameter verwenden kannst. Beispiel

public void TolleMethode(var parameter)
{
    // ...
}

Dies schmeißt ein Kompilierfehler, weil eben nicht zur Entwicklungszeit der konkrete Datentyp ermittelt werden kann.

Aus meiner Sicht kann var schon den Code sauberer halten aber das ist wohl Geschmackssache.

[pkranig2023]

ok danke

[Rabber]

Ich finde, besonders vorteilhaft wird var in Kombination mit LINQ, Lambda, Listen und Co..

---

Wenn Du z.B. eine Liste x erstellen möchtest und die hat im ersten Codieranlauf den Typ int.

List<int> x = ...

Nun programmierst Du weiter und stellst fest, dass eine Collection besser wäre.

Collection<int> x = ...

Wenn Du die Typen explizit programmierst, musst Du im Zweifel div. Stellen anpassen. Bei var ist das reduziert, weil sich an der var-Notation nichts ändert und der Compiler Dir einiges an manueller Tipparbeit abnimmt.

---

Gleiches gilt für komplexe Typen wie Dictionaries.

Dictionary<int, List<string>> dict = ...

vs.

var dict = ...

 

var wird erst dann interessant, wenn man komplexere Codes schreibt, welche weitergehende Features von C# verwenden. Für handelsübliche Variablen a la int, string und Co. finde ich das ehrlich gesagt weniger spannend.

[KeeperOfCoffee]

Soll ich hier noch den dynamic Typ in den Raum werfen (denn man mMn ja eh äußerst selten verwendet), oder macht dies nur alles komplizierter? hmmmm

Bearbeitet 20. November 2018 von KeeperOfCoffee

[Gast D-eath]

Wer sich übrigens näher für die Hintergründe interessiert: https://de.wikipedia.org/wiki/Typinferenz

https://blogs.msdn.microsoft.com/pedram/2007/05/31/local-variable-type-inference-in-c-3-0/

[JimTheLion]

Mal schnell mit angehangen...

Wird var nur direkt bei der Initialisierung verwendet oder auch wenn man ein Objekt durch einen Methodenaufruf zurückbekommt? Z.B.

var whatever = AwesomeWhateverFactory.create();
vs
Whatever whatever = AwesomeWhateverFactory.create();

 

[Whiz-zarD]

vor 13 Minuten schrieb KeeperOfCoffee:

Soll ich hier noch den dynamic Typ in den Raum werfen (denn man mMn ja eh äußerst selten verwendet), oder macht dies nur alles komplizierter? hmmmm

Und das zu Recht! dynamic umgeht ja den Luxus der Typüberprüfung zur Kompilierzeit. D.h. im schlimmsten Fall kommt erst der Fehler beim Kunden vor.

vor 3 Minuten schrieb PVoss:

Wird var nur direkt bei der Initialisierung verwendet oder auch wenn man ein Objekt durch einen Methodenaufruf zurückbekommt? Z.B.

var whatever = AwesomeWhateverFactory.create();
vs
Whatever whatever = AwesomeWhateverFactory.create();

 

Es geht beides, da die Create()-Methode ja einen Rückgabewert hat und whatever ist dann von diesem Typ. Wenn Create() ein object zurückliefert, dann ist whatever ebenfalls ein object.

[JimTheLion]

IC, aber nutzt man das denn auch für Methoden? Bzw. wie ist eure Meinung dazu (In Bezug auf " Über den Nutzen von "var" scheiden sich die Geister. ")

Bei dem Beispiel würde mir die Explizität verloren gehen.

Bearbeitet 20. November 2018 von PVoss

[KeeperOfCoffee]

Gerade eben schrieb PVoss:

Bei dem Beispiel würde mir die Explizität verloren gehen.

Kannst du da mal genauer erklären? Es ist doch bereits vorgegeben, welcher Rückgabetyp es ist. Es wird doch bereits zu Kompilierungszeit ein Typ für die var vergeben.

[Whiz-zarD]

Die Frage ist, ob du die Explizität überhaupt brauchst?
Die Factory gibt dir doch auch nur ein Typ einer abstrakten Klasse oder ein Interface zurück. Die konkrete Implementierung kennst du zur Entwicklungszeit auch nicht.

Ob ich jetzt:

var whatever = AwesomeWhateverFactory.Create();

oder:

IAwesomeWhatever whatever = AwesomeWhateverFactory.Create();

schreibe, hilft mir jetzt auch nicht wirklich weiter, denn im Grunde sagt der Name der Factory schon, was ich zurückbekomme und wenn nicht, dann im Zweifel der Rückgabewert von Create().

Bearbeitet 20. November 2018 von Whiz-zarD

[maestro impostor]

vor 7 Minuten schrieb KeeperOfCoffee:

Kannst du da mal genauer erklären? Es ist doch bereits vorgegeben, welcher Rückgabetyp es ist. Es wird doch bereits zu Kompilierungszeit ein Typ für die var vergeben.

Genau,
deswegen funktioniert

var myVar = null;

auch nicht.

 

vor 6 Minuten schrieb Whiz-zarD:

Die Frage ist, ob du die Explizität überhaupt brauchst?

Bedingt aber eben auch das die Methoden etc. vernünftig und nachvollziehbar benannt sind:

var instance = getNewOnlineAvailableResultInstance();
var instance2 = getNewInstance();

 

Bearbeitet 20. November 2018 von r4phi

[JimTheLion]

vor 9 Minuten schrieb KeeperOfCoffee:

Kannst du da mal genauer erklären?

Für den Leser des Codes.

Wenn ich das erste mal schnell durch den Code scrolle wüsste ich bei

Whatever whatever = AwesomeWhateverFactory.create();

sofort welchen Typ whatever hat.

Bei der var Variante müsste ich mich darauf verlassen, dass sinnvolle Namen vergeben wurde.

Die Frage ist an https://www.python.org/dev/peps/pep-0020/#id3 angelehnt.

vor 8 Minuten schrieb Whiz-zarD:

Die Frage ist, ob du die Explizität überhaupt brauchst?

Naja, ich bin PHP-Entwickler, in meiner Welt gibtes sowas also überhaupt nicht. Bei meinen kurzen Java-Ausflügen fand ich immer cool, dass man direkt die Typen erkennen kann ?

Bearbeitet 20. November 2018 von PVoss

[maestro impostor]

vor 25 Minuten schrieb Whiz-zarD:

Und das zu Recht! dynamic umgeht ja den Luxus der Typüberprüfung zur Kompilierzeit. D.h. im schlimmsten Fall kommt erst der Fehler beim Kunden vor. 

Das musste ich schmerzlich bei Java bzw. Groovy feststellen... in der IDE wird alles schön ohne Fehler kompiliert und ausgeführt. Sobald aber an irgend einer Stelle was falsch ist (bspw. String ansteller einer Objektinstanz an eine Methode übergeben) knallt es an dem Punkt im laufenden Betrieb.

[Whiz-zarD]

vor 8 Minuten schrieb PVoss:

Naja, ich bin PHP-Entwickler, in meiner Welt gibtes sowas also überhaupt nicht.

Nee, da wird der Datentyp gleich ganz weggelassen, weil man ja ganz Toll Strings mit Zahlen addieren kann.

vor 8 Minuten schrieb PVoss:

Naja, ich bin PHP-Entwickler, in meiner Welt gibtes sowas also überhaupt nicht. Bei meinen kurzen Java-Ausflügen fand ich immer cool, dass man direkt die Typen erkennen kann ?

Ab Java 9 besitzt Java auch Type Inference, also var.
https://www.journaldev.com/12849/javase9-var-for-local-variables

Und glaub mir, man kommt auch ohne explizite Typendefinition gut aus. In meiner Firma gab es auch ältere Entwickler, die das sehr zweifelhaft finden aber inzwischen haben sie sich auch daran gewöhnt und denen fehlt auch nichts.

Bearbeitet 20. November 2018 von Whiz-zarD

[Gast D-eath]

vor 4 Minuten schrieb Whiz-zarD:

Nee, da wird der Datentyp gleich ganz weggelassen, weil man ja ganz Toll Strings mit Zahlen addieren kann.

Das ist falsch, zumindest PHP 7 hat mittlerweile Typendeklarationen eingeführt. Damit kann man das Problem abstellen.

[Whiz-zarD]

vor 3 Minuten schrieb D-eath:

Das ist falsch, zumindest PHP 7 hat mittlerweile Typendeklarationen eingeführt. Damit kann man das Problem abstellen.

Mag sein, aber galt es bei PHP nicht immer als ein cooles Feature, dass die Sprache schwach typisiert war?
Ich persönlich finde es noch grauenvoller, wenn eine Sprache schwach- und stark typisiert ist. Der eine macht es so und der andere so. Da ist das Chaos erst recht vorprogrammiert.

[JimTheLion]

vor 21 Minuten schrieb Whiz-zarD:

Mag sein, aber galt es bei PHP nicht immer als ein cooles Feature, dass die Sprache schwach typisiert war?

Kommt drauf an welchen Blog du gelesen hast^^'

Ich mag PHP, aber die schwache Typisierung ist halt echt kacke.

Da kann bei getEntries() auch schonmal null als Rückgabewert rauskommen... und dann wird über alle Ebenen hinweg geprüft ob das null oder ein Array ist. Da sind dann ein Entwicklungsleiter und interne Prozesse gefragt die so einen Kram gleich unterbinden. Deshalb bin ich froh, dass es endlich Rückgabetypehints gibt, damit kann man solche Sachen abfangen und den Leuten die Augen öffnen.

Naja, zumindest bei den Unternehmen die ich innerhalb des letzten Jahres kennengelernt habe wird doch sehr auf die Code-Qualität geachtet, ich denke das Problem ist auch nicht mehr ganz so schlimm wie es vor ein paar Jahren noch war. Den kleinen Web-Buden mit den unmotivierten Leuten denen der Code egal ist wird aber wohl nicht so schnell zu helfen sein.

 

so... sry für den Ausflug in andere Umgebungen ?

Bearbeitet 20. November 2018 von PVoss

[Gast D-eath]

vor 17 Minuten schrieb Whiz-zarD:

Mag sein, aber galt es bei PHP nicht immer als ein cooles Feature, dass die Sprache schwach typisiert war?
Ich persönlich finde es noch grauenvoller, wenn eine Sprache schwach- und stark typisiert ist. Der eine macht es so und der andere so. Da ist das Chaos erst recht vorprogrammiert.

Damit hast du schon Recht, aber es ist ein Schritt in die richtige Richtung. Weiterhin liegt es immer noch an jedem selbst, hohe Qualität zu erzeugen. Auch in Java 9 mit dem var-Schlüsselwort kannst du bescheidenen Code schreiben.