Daten Zuweisung zu Variablen

Talemantros

Ich danke euch für eure Ausführungen.

Vielleicht eins noch, wo ist der Unterschied zwischenm Uint32 und Int64 wie oben beschrieben. Ich finde in meinem Buch nur Int und Uint
lg
Tale

GPC

Talemantros schrieb:

Vielleicht eins noch, wo ist der Unterschied zwischenm Uint32 und Int64 wie oben beschrieben. Ich finde in meinem Buch nur Int und Uint

System.UInt32 -> Vorzeichenlose (kann nur positive Zahlen darstellen) 32-bit Ganzzahl
System.Int64 -> Vorzeichenbehaftete (kann also negative und positive Zahlen darstellen) 64-bit Ganzzahl

System.UInt32 läuft normal als "uint" und System.Int64 als "long". Genauso wie float intern System.Single heißt etc.

Dravere

µ schrieb:

Das ist nicht Sinn und Zweck von var und trägt bestimmt nicht zur Lesbarkeit des Codes bei.
Hast Du dann auch solchen Code? var number = foo();
Zum Glück muss ich mich in sowas nicht einlesen.
Abseits anonymer Typen (wofür var entwickelt wurde), ist sowas nicht verkehrt:
var list = new List<string>();
Ansonsten lieber Hände weg davon und nicht unreflektiert überall einzusetzen, weil es angeblich einfacher ist.

Wozu willst du den Typ wissen? Der Typ ist meistens unnötig und für das Verständnis des Codes unwichtig. Viel wichtiger sind Variablen- und Funktionsnamen.

Eine ausführliche Auseinandersetzung mit dem Thema findest du z.B. hier:
http://blogs.msdn.com/b/ericlippert/archive/2011/04/20/uses-and-misuses-of-implicit-typing.aspx

Vielfach kann var das Verständnis des Codes verbessern, weil es unnötige Informationen entfernt. Wenn du auf den Typ angewiesen bist, dann stimmt meistens etwas in deiner Aufteilung oder Benennung des Codes nicht.

Grüssli

GPC

Dravere schrieb:

Vielfach kann var das Verständnis des Codes verbessern, weil es unnötige Informationen entfernt. Wenn du auf den Typ angewiesen bist, dann stimmt meistens etwas in deiner Aufteilung oder Benennung des Codes nicht.

Ich glaub das ist auch eine Frage, wie man selbst ins Programmieren reingewachsen ist. Ich z.B. bin ein großer Freund von statischen Typsystemen. Insofern bin ich damit aufgewachsen, den Typ hinzuschreiben und "var" war für mich am Anfang schon ganz schön komisch Hat sich angefühlt, als ob man scripted :p Inzwischen nutze ich es aber auch häufig, gerade bei Klassen. Aber meine built-ins bleiben manuell ausgeschrieben

Dravere

GPC schrieb:

Dravere schrieb:

Vielfach kann var das Verständnis des Codes verbessern, weil es unnötige Informationen entfernt. Wenn du auf den Typ angewiesen bist, dann stimmt meistens etwas in deiner Aufteilung oder Benennung des Codes nicht.

Ich glaub das ist auch eine Frage, wie man selbst ins Programmieren reingewachsen ist. Ich z.B. bin ein großer Freund von statischen Typsystemen. Insofern bin ich damit aufgewachsen, den Typ hinzuschreiben und "var" war für mich am Anfang schon ganz schön komisch Hat sich angefühlt, als ob man scripted :p Inzwischen nutze ich es aber auch häufig, gerade bei Klassen.

Naja, ich bin über VBA und dann vor allem C++ ins Programmieren reingekommen. In C++ hatte ich sogar am Anfang noch die microsoft'sche ungarische Notation verwendet. Ich bin allerdings schon vor C# mit var zur Überzeugung gelangt, dass der Typ einer Variable eher unwichtig ist. Das kam unteranderem durch Diskussionen über die ungarische Notation (auch hier im Forum) und durch die Templatemetaprogrammierung, wo es einfach sehr offensichtlich wurde, wie unwichtig der Typ ist im Gegensatz zu Variablennamen und der Schnittstelle eines Typs, heisst den Funktionsnamen.

GPC schrieb:

Aber meine built-ins bleiben manuell ausgeschrieben

Kommt bei mir ganz darauf an. Zum Beispiel string ersetze ich fast überall durch var . Bei den Zahlentypen kommt es ganz darauf an, was ich mache. Solange der Typ aber nicht wichtig ist, nehme ich meistens var .

Grüssli

Das Verständnis von Code ist so subjektiv, dass sich darüber eigentlich nicht diskutieren lässt. Außerdem scheint es mir hochgradig abhängig von der Art Code/Software zu sein, ob var nützlich oder böse ist.

Tatsächlich schreibe ich auch häufig sowas:

var studyRepository = repositoryFactory.getStudyRepository();

Also bei anwendungsweiten Serviceklassen ist mir der Typ egal, weil die Benennung immer identisch und die Anwendung einfach und stets im Gedächtnis ist.
Aber die bedinungslose und durchgehende Verwendung von var halte ich für schlichtweg falsch. Insbesondere bei Teamarbeit. Gegen bewussten Einsatz habe ich nichts.

Sobald der Code schwieriger wird, ist mir die Typinformation ein Hilfsmittel zum Verständnis. Auch als Anker ins Gedächtnis um mich an Details der Typen zu erinnern. Abseits von Datenschubser-Anwendungen ist es manchmal eben überhaupt nicht egal, wie ein Typ intern funktioniert und jedes Stück Information, dass mir Quellcode auf den ersten Blick liefert, von Bedeutung.

(Btw. warum schreit die C++-Gemeinde nach Concepts, wenn die Details eine Templateparameters so unwichtig sind und der Compiler den Rest schon erledigt? Imho nicht nur für verständlichere Compilerausgaben.)

Dravere schrieb:

Wenn du auf den Typ angewiesen bist, dann stimmt meistens etwas in deiner Aufteilung oder Benennung des Codes nicht.

Sorry aber das ist nur ein Totschlagargument, wie man es in dieser oder ähnlicher Form ("Mit dem Design stimmt etwas nicht") leider sehr oft liest.

Mich würde noch interessieren, wie es mit einem Langzeittest aussieht. Also falls jemand var seit längerem (>=1 Jahr) überall oder nahezu überall, wo möglich, verwendet: Wie steht es um die nachträgliche Verständlichkeit von älterem Codes bei Wartungsarbeiten? Also Code der nicht mehr im Gedächtnis ist.

Edit: Ich kann heute keinen geraden Satz mehr formulieren

asc

µ schrieb:

...Außerdem scheint es mir hochgradig abhängig von der Art Code/Software zu sein, ob var nützlich oder böse ist.

Wenn man wie ich unter C# eher kurze Methoden schreibt ist var eigentlich unproblematisch. Ich selbst verwende var (bzw. überlasse Resharper die Konvertierung) bei nicht eingebauten Datentypen, int/bool... schreibe ich aus.

µ schrieb:

...Aber die bedinungslose und durchgehende Verwendung von var halte ich für schlichtweg falsch. Insbesondere bei Teamarbeit.

Auch bei Teamarbeit kann man mit sinnvoller Benennung und tendenziell kurzen Methoden var relativ problemlos einsetzen. Zumal mir der Typ ohnehin angezeigt wird (oder liegt dies am Resharper?).

asc schrieb:

µ schrieb:

...Aber die bedinungslose und durchgehende Verwendung von var halte ich für schlichtweg falsch. Insbesondere bei Teamarbeit.

Auch bei Teamarbeit kann man mit sinnvoller Benennung und tendenziell kurzen Methoden var relativ problemlos einsetzen. Zumal mir der Typ ohnehin angezeigt wird (oder liegt dies am Resharper?).

Hier wird irgendwie implizit unterstellt, dass die Benennung bei var-Gegnern (drastisch formuliert, ich verwende es ja teilweise auch), entweder nicht ernst genommen oder nicht gut ist. Ich gebe mir große Mühe bei den Bezeichnern und nach einigen Jahren glaube ich auch dass sie mir gelingen.
Andere Sache: Wenn die Benennung bei massivem Einsatz von impliziter Typisierung soweit geht, dass der Typ am Ende wieder in dem Bezeichner auftaucht, hat man es imho übertrieben.

List<string> names = getNames();
oder
var namesList = getNames();

Btw. welcher angezeigte Name meinst Du? Also wie sieht das mit Resharper aus?

GPC

µ schrieb:

List<string> names = getNames();
oder
var namesList = getNames();

Ich muss zugeben, die Bezeichnung fooList/fooSequence findet man bei mir oft, weil wenn ich es nur z.B. "names" nenne und hinterher mit foreach drübergehe, dann muss ich ja foreach (var name in names) schreiben und es nervt mich, dass sich die Liste und der einzelne String vom Namen her nur an dem 's' unterscheiden. Da kann ich IntelliSense auch nicht mehr so effektiv nutzen