Forum: Algorithmen, Datenstrukturen und Klassendesign
by Medium,
27. Jan 2014
Ebenso, wie "Integer" immer brav mitgewachsen ist (obwohl es da sogar ursprünglich so garantiert wurde), gelle? ;)
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Medium,
27. Jan 2014
Nettes Beispiel! Ich gebe zu, dass es hier tatsächlich ein Grenzfall ist. Und auch wenn ich bei verketteten Listen durchaus nicht die Nase rümpfen würde, wenn dort jemand "altbacken" mit einer while-Schleife und CurrentItem := CurrentItem.Next; durchrauscht, sehe ich eine potenzielle Vereinfachung durch for..in hier. In solch einem Fall würde ich mir dann aber schon einen explizit benutzten...
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Medium,
25. Jan 2014
Code, bei dem ich erst die Klassenhierarchie studieren müsste um herauszufinden wie meine Schleife läuft (und dies relevant ist), würde ich dem Autor sowas von um die Ohren knallen, das glaubst du gar nicht. Das ist bewusstes torpedieren von Teamarbeit und Produktivität.
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Medium,
24. Jan 2014
Dass etwas geht heisst nicht gleich, dass es auch gut ist. Dass andere dieses etwas gemacht haben ebensowenig, da können jetzt Beispiele noch und nöcher kommen.
Man Verschleiert die Abhängigkeit von einer definierten Reihenfolge durch die Nutzung einer Operation auf einer prinzipiell unsortierten Menge. Dass sie es in der Praxis oftmals dennoch ist, ist nicht Bestandteil des Vorganges, und...
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Medium,
24. Jan 2014
Sehe ich anders. Diese Art der Schleife ist ja gerade darüber definiert, dass sie eine ungeordnete Menge an Elementen iteriert. Würde man sich in einer for..in-Schleife auf ein festgelegtes Iterationsverhalten verlassen, so wäre das extrem schlecht selbstdokumentierender Code. Ein for..to dagegen zeigt direkt eindeutig eine Laufrichtung inkl. Grenzen an. Es hat daher auch durchaus seinen wohl...