Schleifen in der Mitte verlassen

  • macmoonshine schrieb:

    longW schrieb:

    Ich kann mir das nur dadurch erkl;ären, das beim Zupfen, anders als beim Schneiden, die harten Blattteile unzerstört bleiben.

    Aber das Basilikum in einem Pesto ist ja nicht nur geschnitten sondern schon eher püriert. Tofu lässt sich übrigens mit einer selbstgefertigten Sauce aus geschnittenem Basilikum ganz delikat grillen und das schmeckt auch nicht bitter. Wenn ich die Blätter von der Pflanze abzupfe, ist da auch nichts Hartes mehr dran.

    Beim Mörsern geht es ja gerade darum, die Pflanze in der Struktur zu zerstören, um an die Öle zu kommen. Wenn das bitter machen würde …

    Deshalb kommt bei mir das Basilikum auch so etwa 1-2 Minuten vor dem Ende in die Sauce, gerade, wenn ich es weitestgehend unversehrt gelassen habe. Sonst habe ich ein Bruschetta al pomodori – obwohl, das lässt man ja auch mindestens 30 Minuten ziehen.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • dergraf schrieb:

    So, ich hab noch mal meine Ausgabe von "Code Complete" von Steve McConnell rausgesucht und nachgelesen. Der führt eine Studie an, nach der Endlosschleifen, die in der Mitte verlassen werden verständlicher sind als andere Schleifen-Typen, wenn es nötig ist am Ende die Schleife nur zur Hälfte zu durchlaufen. Im übrigen kann ich dieses Buch sowieso allen empfehlen, die meinen so etwas wären nur Kleinigkeiten und egal. Dort werden nicht nur Behauptungen aufgestellt, sie werden auch mit Studienergebnissen und Statistiken untermauert.

    Aber hier in diesem Forum scheint ja Basilikum einen höheren Stellenwert als guter Code einzunehmen...

    Ich hatte bereits ganz am Anfang gesagt, dass man es so bauen soll, wie es der Sache nach ist.

    Dafür braucht man weder ein Buch, noch einen Thread, sondern nur gesunden Menschenverstand.

    Bei Basilikum ist das anders.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • dergraf schrieb:

    So, ich hab noch mal meine Ausgabe von "Code Complete" von Steve McConnell rausgesucht und nachgelesen. Der führt eine Studie an, nach der Endlosschleifen, die in der Mitte verlassen werden verständlicher sind als andere Schleifen-Typen, wenn es nötig ist am Ende die Schleife nur zur Hälfte zu durchlaufen. Im übrigen kann ich dieses Buch sowieso allen empfehlen, die meinen so etwas wären nur Kleinigkeiten und egal. Dort werden nicht nur Behauptungen aufgestellt, sie werden auch mit Studienergebnissen und Statistiken untermauert.

    Aber hier in diesem Forum scheint ja Basilikum einen höheren Stellenwert als guter Code einzunehmen...


    Ääh, ja. Die Studie ist mittlerweile 27 Jahre alt und bezieht sich auf Schüler. Das muss ihre Aussagekraft nicht unbedingt schmälern, aber es könnte sein, dass sich das Software Engineering seitdem leicht geändert hat.

    Anschließend schreibt er, dass loop-with-exit das Black-Box-Prinzip verletzen und dass sie deshalb doch nicht so toll seien. Danach schreibt er, dass sie dann doch eigentlich besser seien als Termination Flags. Und dann schreibt er, dass in New York mal das Telefonsystem wegen eines falschen breaks ausgefallen sei. Und er schreibt, dass viele Breaks Zeichen für schlechten Code seien. Im Anschluss schreibt er, dass man sie in der richtigen Situation benutzen sollte. Abschließend schreibt er, dass man nicht wisse, ob breaks virtuos oder böse seien. Er führt dazu Søren Kierkegaard an, der sich ablebensbedingt leider nicht mehr dagegen wehren kann.

    Fazit: Ja, ääh, nein, ich mein - Jein.

    Ich habe eine gesunde Skepsis vor Mach-meinen-Code-besser-Büchern, die ernsthaft händisches Loop Unrolling empfehlen, weil man damit angeblich ein paar Prozentpunkte Performance rausholen könne. Nicht alles Dunkle auf einem Stück Papier ist wertvoll. Da stehen sicherlich einige nette Sachen drin, aber halt nicht alles.

    Es gibt erheblich interessantere Bücher, z.B. dieses hier.
    Multigrad - 360°-Produktfotografie für den Mac

  • Lucas de Vil schrieb:


    Weiterhin ergibt sich mir eine Anforderung.
    1) Zeig mal die Studie, würde mich interessieren.
    (Auch, wer so besch... +hüstel+ wer die Muße aufbringt, in einer solch prekären Frage repräsentative Studien durchzuführen.)

    Gerne, hier die Literaturstelle:
    Elliot Soloway, Jeffrey Bonar, and Kate Ehrlich. 1983. "Cognitive Strategies and Looping Constructs: An Empirical Study." Communications of the ACM 26, no. 11 (November): 853-60. (cacm.acm.org/magazines/1983/11…nd-looping-constructs/pdf).

    Es wurden verschiedenen Gruppen verschiedene Schleifen vorgesetzt und anschließend das Verständnis des Codes abgefragt. Die Gruppe, deren Schleife die Abbruchbedingung in der Mitte und nicht oben oder unten hatte hat bei diesem Verständnis-Quiz um 25% besser abgeschnitten.

    Lucas de Vil schrieb:

    Es tut mir leid, wenn dich meine Worte irgendwie verletzen sollten. Dennoch schreibe ich das hier ganz unverblümt:
    So empfehlenswert kann das besagte Buch nicht sein, wenn du als Verfechter eben dieses Buches es nicht einmal schaffst uns im Grundsatz die wichtigen Informationen mitzuteilen.

    Wenn dir wichtige Informationen fehlen, wieso fragst du dann nicht? Und was soll das mit dem Buch zu tun haben, dass ich hier nicht irgend etwas hinschreibe was meiner Meinung nach mit dem Problem nichts zu tun hat? Falls du es nicht gemerkt hast, es geht hier nicht um ein konkretes Problem, sondern um eine allgemeine Frage des Programmier-Stils. Und dass dir hier irgend etwas Leid tut glaube ich dir nicht.

    Aber ich weiß jetzt bescheid, in Zukunft werde ich direkt mein Buch konsultieren oder andere Quellen suchen als hier nach etwas allgemeinem zu fragen. Das artet hier ja doch nur wieder (wie ich übrigens befürchtet habe) aus.

  • mattik schrieb:

    Ääh, ja. Die Studie ist mittlerweile 27 Jahre alt und bezieht sich auf Schüler. Das muss ihre Aussagekraft nicht unbedingt schmälern, aber es könnte sein, dass sich das Software Engineering seitdem leicht geändert hat.
    Wohl eher Studenten als Schüler. Aber das dürfte an der Aussage nichts ändern. Und was die gängige Praxis im Software-Engineering ist hat damit doch eigentlich auch nichts zu tun. Es ging dadrum, was besser verstanden wurde. Und gerade da dürfte es besser zu sein einen Studenten zu fragen, als jemanden der durch lange Praxis in festen Mustern denkt.

    mattik schrieb:

    Anschließend schreibt er, dass loop-with-exit das Black-Box-Prinzip verletzen und dass sie deshalb doch nicht so toll seien. Danach schreibt er, dass sie dann doch eigentlich besser seien als Termination Flags. Und dann schreibt er, dass in New York mal das Telefonsystem wegen eines falschen breaks ausgefallen sei. Und er schreibt, dass viele Breaks Zeichen für schlechten Code seien. Im Anschluss schreibt er, dass man sie in der richtigen Situation benutzen sollte. Abschließend schreibt er, dass man nicht wisse, ob breaks virtuos oder böse seien. Er führt dazu Søren Kierkegaard an, der sich ablebensbedingt leider nicht mehr dagegen wehren kann.
    Ja, aber für genau dieses Problem muss das Black-Box-Prinzip verletzt werden. Alles andere resultiert in der Wiederholung von Code, und warum das keine gute Idee ist sollte offensichtlich sein und wurde auch ein paar Seiten vorher noch einmal ausdrücklich erläutert. Und natürlich gibt es dazu auch immer wieder andere Gegenargumente. Aber nachdem ich die alle betrachtet habe bin ich zu dem Schluss gekommen, dass das loop-with-exit-Prinzip für meine Fälle das richtige ist.

    mattik schrieb:

    Ich habe eine gesunde Skepsis vor Mach-meinen-Code-besser-Büchern, die ernsthaft händisches Loop Unrolling empfehlen, weil man damit angeblich ein paar Prozentpunkte Performance rausholen könne. Nicht alles Dunkle auf einem Stück Papier ist wertvoll. Da stehen sicherlich einige nette Sachen drin, aber halt nicht alles.
    Ich würde "Code Complete" jetzt nicht wirklich als "Mach-meinen-Code-besser-Buch" bezeichnen. Es zeigt Dinge auf, die gut oder weniger gut funktionieren und gibt dafür Fakten und zahlen an, die belegen, warum das so ist.

    Aber er empfiehlt ganz bestimmt keine bestimmten Optimierungen, weil man angeblich Performance rausholen kann. Er gibt zwar Optimierungsmöglichkeiten an, und manche sind heutzutage sicherlich mehr als fragwürdig. Aber ganz wegschmeißen sollte man das Kapitel über Optimierung auch nicht. Er führt auch das berühmte Zitat "Premature optimization is the root of all evil" an und betont regelmäßig dass man den Erfolg von Optimierungen messen muss und sie auch wieder entfernen soll, wenn sie sich nicht lohnen.

  • Amin Negm-Awad schrieb:

    Ich hatte bereits ganz am Anfang gesagt, dass man es so bauen soll, wie es der Sache nach ist.

    Natürlich, ich habe auch nicht vor irgend welchen Code zu bauen, nur weil es geht. Und natürlich baue ich es so, wie es der Sache nach ist, um das mal so auszudrücken. Das schließt aber trotzdem nicht aus, dass es mehrere äquivalente Möglichkeiten gibt. Die beiden, die mir eingefallen sind habe ich schon ganz am Anfang geschrieben, und später wurden noch einige andere genannt. Und wenn es mehrere Möglichkeiten gibt, die selben Aktionen in Code auszudrücken sollte man wohl auch mal darüber reden dürfen, was vom Stil, der Les- und Wartbarkeit am besten ist.

    Amin Negm-Awad schrieb:

    Bei Basilikum ist das anders.

    Dann mach dir halt deinen eigenen Basilikum-Thread auf und stör hier nicht. Dort werde ich dich sicherlich auch nicht mit Fragen des Programmier-Stils belästigen.

  • dergraf schrieb:

    Amin Negm-Awad schrieb:

    Ich hatte bereits ganz am Anfang gesagt, dass man es so bauen soll, wie es der Sache nach ist.

    Natürlich, ich habe auch nicht vor irgend welchen Code zu bauen, nur weil es geht. Und natürlich baue ich es so, wie es der Sache nach ist, um das mal so auszudrücken. Das schließt aber trotzdem nicht aus, dass es mehrere äquivalente Möglichkeiten gibt. Die beiden, die mir eingefallen sind habe ich schon ganz am Anfang geschrieben, und später wurden noch einige andere genannt. Und wenn es mehrere Möglichkeiten gibt, die selben Aktionen in Code auszudrücken sollte man wohl auch mal darüber reden dürfen, was vom Stil, der Les- und Wartbarkeit am besten ist.

    Man kann darüber nicht abstrakt reden. Ist dch einfach: Wenn du eine Schleife baust, die etwa nach einem Ziel sucht, dann wird man das Ergebnis als Schleifenabbruchbedingung nehmen. Wenn man – etwa aufgrund wiedergefundener Zwischenergebnisse – sieht, dass man nicht wieter suchen muss, dann wird man hier herausspringen. Warum? Weil es die Sache abbildet.

    Was ist jetzt besser? Eine offensichtlich völlig unsinnige Frage, die auch ganz offenkundig kein Buch und keine empirische Studie beantworten kann. Sie kann es für einen bestimmten Fall, den du höchstwahrscheinlich nicht hast.

    dergraf schrieb:

    Amin Negm-Awad schrieb:

    Bei Basilikum ist das anders.

    Dann mach dir halt deinen eigenen Basilikum-Thread auf und stör hier nicht. Dort werde ich dich sicherlich auch nicht mit Fragen des Programmier-Stils belästigen.



    Wie gesagt sind das drängendere Fragen.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • dergraf schrieb:

    Lucas de Vil schrieb:


    Weiterhin ergibt sich mir eine Anforderung.
    1) Zeig mal die Studie, würde mich interessieren.
    (Auch, wer so besch... +hüstel+ wer die Muße aufbringt, in einer solch prekären Frage repräsentative Studien durchzuführen.)

    Gerne, hier die Literaturstelle:
    Elliot Soloway, Jeffrey Bonar, and Kate Ehrlich. 1983. "Cognitive Strategies and Looping Constructs: An Empirical Study." Communications of the ACM 26, no. 11 (November): 853-60. (cacm.acm.org/magazines/1983/11…nd-looping-constructs/pdf).

    "There is no abstract available for this article. The full text of this article is premium content."
    Sehr hilfreich.

    dergraf schrieb:

    Es wurden verschiedenen Gruppen verschiedene Schleifen vorgesetzt und anschließend das Verständnis des Codes abgefragt. Die Gruppe, deren Schleife die Abbruchbedingung in der Mitte und nicht oben oder unten hatte hat bei diesem Verständnis-Quiz um 25% besser abgeschnitten.

    Sowas. Würden in der Studie Kinder befragt wäre die Trefferquote wohl noch höher gewesen.
    Man darf nicht vergessen: es ist eine englische Studie. Für ein englischsprachiges Kind mit grundlegenden Mathematikverständnissen lesen sich die üblichen Schleifen dann wie folgt.

    C-Quellcode

    1. solange(x<10)
    2. {
    3. berechne(x*2);
    4. x=x+1;
    5. }

    C-Quellcode

    1. für(; x<10; berechne(x*2), x=x+1);

    C-Quellcode

    1. mach
    2. {
    3. berechne(x*2);
    4. x=x+1;
    5. } wiederholt bis (x>=10);

    C-Quellcode

    1. solange(wahr)
    2. {
    3. wenn(x>=10)
    4. {
    5. breche ab;
    6. }
    7. berechne(x*2)
    8. x=x+1;
    9. }


    dergraf schrieb:


    Wenn dir wichtige Informationen fehlen, wieso fragst du dann nicht?
    Und was soll das mit dem Buch zu tun haben, dass ich hier nicht irgend etwas hinschreibe was meiner Meinung nach mit dem Problem nichts zu tun hat?

    Okay, dann noch mal:
    Was willst du eigentlich?
    Deine Eingangsfrage war sinngemäß 'Welchen Stil dieser beiden Beispiele würdet ihr bevorzugen und warum?', und darauf hast du Antworten bekommen.
    Diese Antworten gefielen dir jedoch nicht und du hast angemerkt 'Was wäre denn, wenn das alles anders aussähe als es in dem Beispiel tut?' sowie 'Ich will aber Seiteneffekte in meinen Schleifen vermeiden!'
    Dann erklärt man dir, dass man Schleifenabbrüche wo es geht vermeiden möchte, und du kommst mit irgendwelchen vollkommen veralteten und eher nichtssagenden Studien um uns zu überzeugen, dass abgebrochene Schleifen voll toll sein.
    Den Konter Mattiks, dass der Autor selbst trotz der via Studie bewiesenen Lesbarkeit zum sorgfältigen Einsatz solcher Konstrukte warnt, übergehst du auch.

    Wie hier, trotz angeschnittener Basilikumfrage, bereits mehrfach erwähnt wurde, sind Schleifen immer Konstrukte, die an die jeweilige Situation angepasst werden.

    dergraf schrieb:


    Falls du es nicht gemerkt hast, es geht hier nicht um ein konkretes Problem, sondern um eine allgemeine Frage des Programmier-Stils. Und dass dir hier irgend etwas Leid tut glaube ich dir nicht.

    Momentan tut mir leid, so viel Energie in das Lesen dieses Threads gesteckt zu haben. Entgegen deines Eingangsposts willst du nämlich gar nicht diskutieren, sondern recht bekommen.
    Hätte ich mich in der Zeit doch mal lieber nach nem Piercer für neue Snakebites umgesehen...
    (Denn Basilikum reizt mich nun gar nicht. ;))
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Ich habe die ganze Zeit nicht verstanden, warum die Basilikumfrage off-topic sein sollte. Die Frage, wann und wie man eine Schleife verlassen sollte, und die Frage, wann und wie man Basilikum in eine Tomatensauce geben sollte, sind doch gar nicht so weit voneinander entfernt. Dabei musste ich an an diese Stelle denken:
    [...] do what experienced programmers do when encountering a new language: look at a few different examples. Don't just print out and follow the first recipe you find; that'd be like downloading a random executable and running it. [...] Pull up a couple of examples, consider what the authors were doing, and ask yourself what makes their "code" (recipe) work and what parts of their "code" apply to what you want to do.

    Jeff Potter: Cooking for Geeks, O'Reilly 2010, S. 22
    Multigrad - 360°-Produktfotografie für den Mac

  • Ich dachte immer, dass IT-Geeks nur Pizza essen – wegen der modularen Bauweise. Was bedeutet eigentlich in diesem Zusammenhang später Bindung? Wenn ich es mir überlege, will ich es doch nicht so genau wissen. Frage zurückgestellt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Auch Aufläufe lassen sich modular aufbauen.
    (Der Laden ist übrigens sehr zu empfehlen, sollte mal wer in Hamburg vorbei schauen)

    Mattik: Im Gegensatz zu dem Herrn im Video habe ich leider keinen Stickstoffbehälter griffbereit. Also eher nein.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • dergraf schrieb:


    Elliot Soloway, Jeffrey Bonar, and Kate Ehrlich. 1983. "Cognitive Strategies and Looping Constructs: An Empirical Study." Communications of the ACM 26, no. 11 (November): 853-60. (cacm.acm.org/magazines/1983/11…nd-looping-constructs/pdf).

    Habs mal überflogen. Sehr geil, damals noch hier die Stimmung "Jeder sollte etwas programmieren können!", hach. Heute ist man schon froh, wenn die Jugendlichen einen Internehtführerschein oder sowas machen...

    Der Artikel bezieht sich auf Pascal, ist aber eigentlich egal. Die Argumentation ist:
    Aufgabenstellung: Schreibe ein Programm, was nach einer Zahl fragt. Wenn Die Zahl 9999 ist, wird abgebrochen, und der Mittelwert aller zuvor eingegebenen Zahlen ausgegeben. Angeblich haben damit viele Studenten sogar ein Problem.
    Die im Paper vorgegebene Musterlösung ist ähnlich wie die, auf die sich hier allgemein geeinigt wurde, etwa

    C-Quellcode

    1. read(num);
    2. while(num!=9999) {
    3. sum += num;
    4. count += 1;
    5. read(num);
    6. }

    Die Argumentation dagegen ist nun, dass in einem Schleifendurchlauf stehts der i-te Wert verarbeitet und dann der (i+1)-te Wert gelesen wird. Dies sei nicht so intuitiv und verwirrend und macht es "kognitiv" dem Programmierer schwieriger.
    Alternativ sei die bessere Variante:

    C-Quellcode

    1. while(true) {
    2. read(num);
    3. if(num==9999) break;
    4. sum += num;
    5. count += 1;
    6. }

    Hier geht innerhalb der Schleife alles schön einfach und offensichtlich daher: Erst einlesen, dann schauen, obs OK ist, und letztendlich verarbeiten.

    Ob das ganze jetzt irgendeine Aussagekraft hat, oder praktische Relevanz will ich nicht beurteilen. Ich persönlich bin kein besonderer Fan von while(true)...break.
    ♥C++