Diskussion:Arbeiten mit .NET: C-Sharp/ Arbeitsablauf/ Kontrollstrukturen/ Schleifen

Datatable-Beispiel finde ich schlecht

, weil das zu viel Grundwissen voraussetzt. Ich denke, dass man das an dieser Stelle weglassen sollte. -- C.hahn 17:39, 23. Mai 2007 (CEST)

Auch richtig, insbesondere wird es einem Einsteiger schwer fallen, damit ein lauffähiges Beispiel hinzubasteln. Zusätzlich ist Rows auch nur eine den folgenden Array-Beispielen mit int[] absolut gleichwertige Datenstruktur. Man lernt also nichts. Ich bin auch dafür das wegzumachen. --WikiBookPhil 02:34, 23. Mai 2008 (CEST)

Endlosschleifen

Die Aussage, dass es was gutes hätte solche eine Schleife zu impülementieren halte ich gelinde gesagt für Blödsinn. Man sollte einen Programmierneuling eher den Ratschlag geben eine Endlosschleife immer mit einer Variablen auszustatten, die es notfalls gestattet diese Schleife auf normale Weise zu verlassen. Aus meiner Sicht sollte auch vor der Verwendung von break und exit gewarnt werden, da man schnell Spagetticode erzeugt und sich keine Gedanken über die wirkliche Struktur seines Programms macht. -- C.hahn 17:44, 23. Mai 2007 (CEST)

Das sehe ich genauso. Es gibt sinnvolle Anwendungen solcher Endlosschleifen ohne "externe Steuervariable", z.B. wenn ein Thread nach Eintritt eines Events Daten aus einer Queue ausliest und bearbeitet und man vorhat, ihn mit ThreadAbort() zu beenden, weil die Thread-Routine statisch ist oder sich in einer "fremden" Klasse befindet. In solchen Fällen kann man unter Umständen nicht einfach ein

if (Bedingung) break;

einbauen.

Der Hinweis, dass Programme, die auf irgendwas aufpassen (Watchdogs), solche "Techniken" benutzen stimmt so auch nicht und der Hinweis auf Multithreading als Trick, die Rechnerauslastung zu vermeiden ist auch im besten Falle irreführend. Ich schlage vor, wenn sich niemand meldet, der was dagegen hat, werde ich das mal überarbeiten.--WikiBookPhil 02:31, 23. Mai 2008 (CEST)

break

Das break-Beispiel ist auch nicht ideal, da sich der gleiche Effekt durch Verwendung einer while-Schleife (also Kopfschleife) ohne break auch direkt erreichen lässt. Prinzipiell wird natürlich die Wirkung von break dadurch klar, wenn aber jemand (ein richtiger Einsteiger) mit diesem WikiBook das Programmieren lernen will, wird sein Stil gleich am Anfang versaut. --WikiBookPhil 02:38, 23. Mai 2008 (CEST)

Warum ich den Abschnitt "Steuerung von Endlosschleifen" gelöscht habe

Ist ja oben schon teilweise angesprochen worden: Die Beispiele dort waren keine "Endlosschleifen", sondern einfach nur in sehr schlechtem Stil programmierte herkömmliche Schleifen. (Dass break vermieden werden sollte, darauf wird ja sogar im Text selber verwiesen.) Das bringt den Leser auf ein zu schmales Brett. --Berntie 13:30, 6. Feb. 2009 (CET)

Verwertbarkeit

Da das Buch wohl recycelt werden soll, hab ich mal ein wenig drübergeschaut. Fazit: Was auf dieser Seite steht sollte z.B. komplett verworfen werden.

• Gezählt wird z.B. von 1 bis <= Endwert (statt 0 bis < Endwert), um dann tatsächlich mit i-1 auf eine Datenbanktabelle zuzugreifen.
• Dann wird ständig von Abbruchbedingung geredet im Zusammenhang mit while und for. Tatsächlich handelt es ja um das Gegenteil, also eine Schleifenbedingung, also die Bedingung, unter der die Schleife läuft. Andere Sprachen kennen z.B. until, bei der die Bedingung eben die ist, die zum Abbruch führt, also eine tats. Abbruchbedingung.
• Dann sehr umständliche Erklärungen, hier zur while-Schleife: "Diese Schleifen prüfen bevor sie den Schleifenrumpf das erste Mal durchlaufen, ob die Abbruchbedingung bereits eingetreten ist. Sie werden also mindestens 0 Mal und höchstens bis zum Eintreten der Abbruchbedingung durchlaufen:" Wieso beim ersten Mal? Es wird doch jedesmal geprüft. Klar, ich weiß, was zum Ausdruck gebracht werden sollte, was aber misslingt.
• Was dann aber völlig fehlt, ist die Information, dass die Bedingung nur etwas sein darf, das einen boolschen Wert liefert. Kennt man ja von anderen Sprachen auch anders.

Also, lieber auf die Übernahme in ein neues Buch verzichten. --84.131.152.164 23:21, 5. Jan. 2010 (CET)

Langsam verstehe ich, was du damit gemeint hast, das Buch sei schlecht! Ich habe nochmals das Praxisbeispiel angeschaut. Fazit: Es ist nicht nur viel zu komplizert (Arrays gehören noch nicht rein), schlecht bzw. gar nicht erklärt UND FALSCH (Die berechneten Primzahlen sind überhaupt nicht komplett).

Was heisst, das Buch sollte recyclet werden? Brauchbar machen oder löschen? -- Sophieb 23:31, 7. Jan. 2010 (CET)

Juetho erwägt, das Buch in sein Arbeiten_mit_.NET zu integrieren oder zumindest als Grundlage für ein C#-Buch zu nehmen. Ich fürchte, neu schreiben geht schneller. Selbst die Struktur ist nicht toll. Thema "Datenstrukturen" kommt ganz am Ende, noch hinter C/S-Programmierung, Threads, Plug-ins. Zumindest die 2 oder 3 wichtigsten, z.B. Arrays (hast du ja auch erwähnt) und assoziative Arrays, gehören ganz weit nach vorne, zumal das durchaus motivierende Themen sind. --84.131.152.152 10:30, 8. Jan. 2010 (CET)

Diese Diskussion sollte besser zentral geführt werden: unter Diskussion:Arbeiten mit .NET/ Inhaltsverzeichnis oder notfalls unter Wikibooks:Seiten zum gleichen Thema (aber dort war die Diskussion schon zu weit gegangen, sodass ich mit Arbeiten mit .NET begonnen hatte).

Mein Anfangsproblem war, dass der Bereich "Datenverarbeitung" überhaupt fehlt und die Bücher zu C# und VB zu großen Teilen nicht sprachspezifisch, sondern NET-lastig sind – daher mein Vorschlag zur Buchreihe. Die vorhandenen Teile sollten übernommen werden, damit bisherige Arbeit nicht verloren ist und nicht alles neu geschrieben werden muss.

Ich sehe aber schon, dass ich mich zu sehr auf die Gliederung konzentriert hatte (ich weiß, auch da gibt es Verbesserungsmöglichkeiten) und zu wenig auf die Inhalte der Seiten.

Aber unabhängig von allen Mängeln: Wenn Wikibooks etwas bedeuten soll, dann gehören NET-Bücher dazu. Dann sollte man aber auch Qualität bringen, und dazu sind Mitstreiter nötig. Wie wäre es mit euch? -- Jürgen 12:47, 8. Jan. 2010 (CET)

Nein, gerade für die Qualität sind Mitstreiter Gift. Je weniger Autoren ein Buch hat, desto besser wird es (vorausgesetzt es sind fähige Autoren). Ideal ist es eben, wenn einer vielleicht 80%-90% leistet und dabei einige Themen komplett "auf Lücke" setzt (vielleicht Threads, reguläre Ausdrücke, GUI), die dann von anderen sinnvoll ergänzt werden. Dass über die gesamte Breite eines Buches Mehrere dran arbeiten, geht sicherlich schief, führt aber auf jeden Fall zu Qualitätseinbußen. Wenn der Buchinitiator nur aus Zeitmangel Mitstreiter sucht, dann sollte er es klar bleiben lassen. --84.131.152.152 13:24, 8. Jan. 2010 (CET)

Ach so, ich soll also C# und Datenbanken und WinForms und WPF (ach ne, davon habe ich noch keine Ahnung) und ASP.NET (ach ne, davon weiß ich auch nichts) usw. weitgehend alleine schreiben, dazu auch gleich noch VB.NET und Delphi.Prism. Ich habe nirgends von Zeitmangel geschrieben, sondern nur davon, dass das Thema NET so umfangreich ist. Danke für den Vorschlag! -- Jürgen 14:12, 8. Jan. 2010 (CET)

Missverständnis. GUI war ein schlechtes Beispiel, denn das wäre ein eigenes Buch. Nein, du musst in der Lage sein, die kleinste geschlossene Einheit, nämlich ein(!) Buch alleine schreiben können, z.B. eines zur Sprache C#, das aber ja vielleicht auch ein Kapitel zu den regulären Ausdrücken haben soll, wovon du aber vielleicht nicht soviel Ahnung hast, und dass dann von mir geschrieben würde. Nur so kann Mitarbeit an einem(!) Buch zu einem nennenswerten Anteil funktionieren.

Dass all die .NET-Bücher, die du im Sinn hast, von unterschiedlichen Autoren sein können und müssen, ist klar. Dass du all diese Bücher unter einem Hut unterbringen willst, ... gut, das ist deine Passion. Ich denke, du wirst mit 2 oder 3 Büchern in Vorlage gehen müssen (das sind erstmal ein paar Mannjahre ;-)), um andere davon überzeugen zu können. Die meisten .NET-Bücher-Ideen scheitern schon an der Urheberrechtsproblematik bei Screenshots. Wie willst du ein lesenswertes Buch über WinForms oder WPF schreiben, ohne Dialoge abzubilden? --84.131.152.152 14:56, 8. Jan. 2010 (CET)