[{"@context":"http:\/\/schema.org\/","@type":"BlogPosting","@id":"https:\/\/wiki.edu.vn\/wiki16\/2021\/01\/22\/strukturierte-programmierung-wikipedia\/#BlogPosting","mainEntityOfPage":"https:\/\/wiki.edu.vn\/wiki16\/2021\/01\/22\/strukturierte-programmierung-wikipedia\/","headline":"Strukturierte Programmierung – Wikipedia","name":"Strukturierte Programmierung – Wikipedia","description":"Programmierparadigma zur Verbesserung von Klarheit, Qualit\u00e4t und Entwicklungszeit durch Verwendung von Kontrollstrukturen Strukturierte Programmierung ist ein Programmierparadigma, das darauf abzielt,","datePublished":"2021-01-22","dateModified":"2021-01-22","author":{"@type":"Person","@id":"https:\/\/wiki.edu.vn\/wiki16\/author\/lordneo\/#Person","name":"lordneo","url":"https:\/\/wiki.edu.vn\/wiki16\/author\/lordneo\/","image":{"@type":"ImageObject","@id":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","height":96,"width":96}},"publisher":{"@type":"Organization","name":"Enzyklop\u00e4die","logo":{"@type":"ImageObject","@id":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","url":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","width":600,"height":60}},"image":{"@type":"ImageObject","@id":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/e\/ec\/Structured_program_patterns.png","url":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/e\/ec\/Structured_program_patterns.png","height":"125","width":"700"},"url":"https:\/\/wiki.edu.vn\/wiki16\/2021\/01\/22\/strukturierte-programmierung-wikipedia\/","wordCount":7878,"articleBody":"Programmierparadigma zur Verbesserung von Klarheit, Qualit\u00e4t und Entwicklungszeit durch Verwendung von Kontrollstrukturen  Strukturierte Programmierung ist ein Programmierparadigma, das darauf abzielt, die Klarheit, Qualit\u00e4t und Entwicklungszeit eines Computerprogramms zu verbessern, indem die strukturierten Kontrollflusskonstrukte Auswahl (wenn \/ dann \/ sonst) und Wiederholung (w\u00e4hrend und f\u00fcr), Blockstrukturen und Unterprogramme.Es entstand in den sp\u00e4ten 1950er Jahren mit dem Erscheinen der Programmiersprachen ALGOL 58 und ALGOL 60,[1]  mit letzterem einschlie\u00dflich Unterst\u00fctzung f\u00fcr Blockstrukturen.  Zu den Faktoren, die zu seiner Popularit\u00e4t und weit verbreiteten Akzeptanz zun\u00e4chst in der Wissenschaft und sp\u00e4ter bei Praktikern beitragen, geh\u00f6rt die Entdeckung des heutigen Satzes \u00fcber strukturierte Programme im Jahr 1966.[2]  und die Ver\u00f6ffentlichung des einflussreichen offenen Briefes “Go To Statement Considered Harmful” im Jahr 1968 durch den niederl\u00e4ndischen Informatiker Edsger W. Dijkstra, der den Begriff “strukturierte Programmierung” pr\u00e4gte.Strukturierte Programmierung wird am h\u00e4ufigsten mit Abweichungen verwendet, die in bestimmten F\u00e4llen klarere Programme erm\u00f6glichen, z. B. wenn eine Ausnahmebehandlung durchgef\u00fchrt werden muss.  Table of ContentsElemente[edit]Kontrollstrukturen[edit]Unterprogramme[edit]Bl\u00f6cke[edit]Strukturierte Programmiersprachen[edit]Geschichte[edit]Theoretische Grundlage[edit]Debatte[edit]Ergebnis[edit]H\u00e4ufige Abweichungen[edit]Vorzeitiger Ausstieg[edit]Ausnahmebehandlung[edit]Mehrfacheintrag[edit]Zustandsautomaten[edit]Siehe auch[edit]Verweise[edit]Zitate[edit]Quellen[edit]Externe Links[edit]Elemente[edit]Kontrollstrukturen[edit]Nach dem Satz des strukturierten Programms bestehen alle Programme aus Kontrollstrukturen:“Reihenfolge”;  geordnete Anweisungen oder Unterprogramme, die nacheinander ausgef\u00fchrt werden.“Auswahl”;  Je nach Status des Programms wird eine oder mehrere Anweisungen ausgef\u00fchrt.  Dies wird normalerweise mit Schl\u00fcsselw\u00f6rtern wie ausgedr\u00fcckt if..then..else..endif.  Die bedingte Anweisung sollte mindestens eine wahre Bedingung haben und jede Bedingung sollte einen Austrittspunkt bei max.“Wiederholung”;  Eine Anweisung oder ein Block wird ausgef\u00fchrt, bis das Programm einen bestimmten Status erreicht oder Operationen auf jedes Element einer Sammlung angewendet wurden.  Dies wird normalerweise mit Schl\u00fcsselw\u00f6rtern wie ausgedr\u00fcckt while, repeat, for oder do..until.  Oft wird empfohlen, dass jede Schleife nur einen Einstiegspunkt hat (und in der urspr\u00fcnglichen Strukturprogrammierung auch nur einen Austrittspunkt, und einige Sprachen erzwingen dies).“Rekursion”;  Eine Anweisung wird ausgef\u00fchrt, indem sie sich wiederholt aufruft, bis die Beendigungsbedingungen erf\u00fcllt sind.  Rekursive Schleifen sind zwar in der Praxis iterativen Schleifen \u00e4hnlich, k\u00f6nnen jedoch rechnerisch effizienter sein und werden als kaskadierender Stapel unterschiedlich implementiert.  Unterprogramme[edit]Unterprogramme;  Aufrufbare Einheiten wie Prozeduren, Funktionen, Methoden oder Unterprogramme werden verwendet, um zu erm\u00f6glichen, dass eine Sequenz durch eine einzelne Anweisung referenziert wird.Bl\u00f6cke[edit]Bl\u00f6cke werden verwendet, um zu erm\u00f6glichen, dass Gruppen von Anweisungen so behandelt werden, als w\u00e4ren sie eine Anweisung. Blockstrukturiert Sprachen haben eine Syntax zum formellen Einschlie\u00dfen von Strukturen, z. B. eine if-Anweisung in Klammern mit if..fi wie in ALGOL 68 oder einem Codeabschnitt in Klammern von BEGIN..END, wie in PL \/ I und Pascal, Leerzeicheneinr\u00fcckung wie in Python – oder die geschweiften Klammern {...} von C und vielen sp\u00e4teren Sprachen.  Strukturierte Programmiersprachen[edit]Es ist m\u00f6glich, strukturierte Programmierung in jeder Programmiersprache durchzuf\u00fchren, obwohl es vorzuziehen ist, so etwas wie eine prozedurale Programmiersprache zu verwenden.  Einige der Sprachen, die urspr\u00fcnglich f\u00fcr die strukturierte Programmierung verwendet wurden, umfassen: ALGOL, Pascal, PL \/ I und Ada, aber die meisten neuen prozeduralen Programmiersprachen seit dieser Zeit enthalten Funktionen zur F\u00f6rderung der strukturierten Programmierung und manchmal absichtlich ausgelassene Funktionen – insbesondere GOTO – in einem Bem\u00fchungen, die unstrukturierte Programmierung zu erschweren.Strukturierte Programmierung (manchmal auch als modulare Programmierung bekannt[citation needed]) erzwingt eine logische Struktur des zu schreibenden Programms, um es effizienter und einfacher zu verstehen und zu \u00e4ndern.Geschichte[edit]Theoretische Grundlage[edit]Der Satz des strukturierten Programms liefert die theoretische Grundlage der strukturierten Programmierung.  Es hei\u00dft, dass drei M\u00f6glichkeiten zum Kombinieren von Programmen – Sequenzierung, Auswahl und Iteration – ausreichen, um eine berechenbare Funktion auszudr\u00fccken.  Diese Beobachtung stammt nicht aus der strukturierten Programmierbewegung;  Diese Strukturen reichen aus, um den Befehlszyklus einer Zentraleinheit sowie den Betrieb einer Turingmaschine zu beschreiben.  Daher f\u00fchrt ein Prozessor immer ein “strukturiertes Programm” in diesem Sinne aus, selbst wenn die Anweisungen, die er aus dem Speicher liest, nicht Teil eines strukturierten Programms sind.  Die Autoren schreiben das Ergebnis jedoch normalerweise einem Artikel von B\u00f6hm und Jacopini aus dem Jahr 1966 zu, m\u00f6glicherweise weil Dijkstra diesen Artikel selbst zitiert hat.[4]  Der Satz \u00fcber strukturierte Programme befasst sich nicht mit dem Schreiben und Analysieren eines n\u00fctzlich strukturierten Programms.  Diese Probleme wurden in den sp\u00e4ten 1960er und fr\u00fchen 1970er Jahren mit wichtigen Beitr\u00e4gen von Dijkstra, Robert W. Floyd, Tony Hoare, Ole-Johan Dahl und David Gries angegangen.Debatte[edit]PJ Plauger, ein fr\u00fcher Anwender der strukturierten Programmierung, beschrieb seine Reaktion auf den Satz des strukturierten Programms:Wir Konvertiten schwenkten diese interessante Neuigkeit unter die Nase der nicht rekonstruierten Assembler-Programmierer, die immer wieder verdrehte Logik hervorbrachten und sagten: “Ich wette, das kann ich nicht strukturieren.”  Weder der Beweis von B\u00f6hm und Jacopini noch unsere wiederholten Erfolge beim Schreiben von strukturiertem Code brachten sie einen Tag fr\u00fcher herum, als sie bereit waren, sich selbst zu \u00fcberzeugen.[5]Donald Knuth akzeptierte das Prinzip, dass Programme unter Ber\u00fccksichtigung der Beweisbarkeit geschrieben werden m\u00fcssen, aber er war anderer Meinung (und immer noch anderer Meinung)[citation needed]) mit der Abschaffung der GOTO-Erkl\u00e4rung.  In seiner Arbeit von 1974 “Strukturierte Programmierung mit Gehe zu Anweisungen”,[6]  Er gab Beispiele, bei denen er glaubte, dass ein direkter Sprung zu klarerem und effizienterem Code f\u00fchrt, ohne die Beweisbarkeit zu beeintr\u00e4chtigen.  Knuth schlug eine lockerere strukturelle Einschr\u00e4nkung vor: Es sollte m\u00f6glich sein, ein Flussdiagramm eines Programms mit allen Vorw\u00e4rtszweigen links, allen R\u00fcckw\u00e4rtszweigen rechts und ohne sich kreuzenden Zweigen zu zeichnen.  Viele derjenigen, die sich mit Compilern und Graphentheorie auskennen, haben sich daf\u00fcr ausgesprochen, nur reduzierbare Flussgraphen zuzulassen[when defined as?].[who?]Theoretiker der strukturierten Programmierung gewannen in den 1970er Jahren einen wichtigen Verb\u00fcndeten, nachdem der IBM-Forscher Harlan Mills seine Interpretation der Theorie der strukturierten Programmierung auf die Entwicklung eines Indexierungssystems f\u00fcr anwendete Die New York Times Forschungsdatei.  Das Projekt war ein gro\u00dfer technischer Erfolg, und Manager anderer Unternehmen f\u00fchrten es zur Unterst\u00fctzung der Einf\u00fchrung einer strukturierten Programmierung an, obwohl Dijkstra kritisierte, wie sich Mills ‘Interpretation von der ver\u00f6ffentlichten Arbeit unterschied.[citation needed]Noch 1987 war es m\u00f6glich, die Frage der strukturierten Programmierung in einem Informatikjournal zu stellen.  Frank Rubin tat dies in diesem Jahr mit einem offenen Brief mit dem Titel “GOTO als sch\u00e4dlich” als sch\u00e4dlich “.[7]  Es folgten zahlreiche Einw\u00e4nde, darunter eine Antwort von Dijkstra, die sowohl Rubin als auch die Zugest\u00e4ndnisse anderer Schriftsteller bei der Beantwortung scharf kritisierte.Ergebnis[edit]Bis zum Ende des 20. Jahrhunderts waren fast alle Informatiker davon \u00fcberzeugt, dass es n\u00fctzlich ist, die Konzepte der strukturierten Programmierung zu lernen und anzuwenden.  Hochrangige Programmiersprachen, denen urspr\u00fcnglich Programmierstrukturen fehlten, wie FORTRAN, COBOL und BASIC, haben sie jetzt.H\u00e4ufige Abweichungen[edit]W\u00e4hrend goto inzwischen weitgehend durch die strukturierten Konstrukte Auswahl (wenn \/ dann \/ sonst) und Wiederholung (w\u00e4hrend und f\u00fcr) ersetzt wurde, sind nur wenige Sprachen rein strukturiert.  Die h\u00e4ufigste Abweichung, die in vielen Sprachen auftritt, ist die Verwendung einer return-Anweisung zum vorzeitigen Verlassen eines Unterprogramms.  Dies f\u00fchrt zu mehreren Austrittspunkten anstelle des einzelnen Austrittspunkts, der f\u00fcr die strukturierte Programmierung erforderlich ist.  Es gibt andere Konstruktionen, um F\u00e4lle zu behandeln, die bei der rein strukturierten Programmierung umst\u00e4ndlich sind.Vorzeitiger Ausstieg[edit]Die h\u00e4ufigste Abweichung von der strukturierten Programmierung ist das fr\u00fchzeitige Verlassen einer Funktion oder Schleife.  Auf der Ebene der Funktionen ist dies a return Erkl\u00e4rung.  Auf der Ebene der Schleifen ist dies a break Anweisung (Schleife beenden) oder continue Anweisung (Beenden Sie die aktuelle Iteration, fahren Sie mit der n\u00e4chsten Iteration fort).  Bei der strukturierten Programmierung k\u00f6nnen diese durch Hinzuf\u00fcgen zus\u00e4tzlicher Zweige oder Tests repliziert werden. Bei R\u00fcckgaben aus verschachteltem Code kann dies jedoch zu einer erheblichen Komplexit\u00e4t f\u00fchren.  C ist ein fr\u00fches und prominentes Beispiel f\u00fcr diese Konstrukte.  Einige neuere Sprachen haben auch “beschriftete Unterbrechungen”, die das Ausbrechen von mehr als nur der innersten Schleife erm\u00f6glichen.  Ausnahmen erm\u00f6glichen auch einen vorzeitigen Ausstieg, haben jedoch weitere Konsequenzen und werden daher im Folgenden behandelt.Mehrere Exits k\u00f6nnen aus verschiedenen Gr\u00fcnden auftreten, meistens entweder, weil das Unterprogramm keine Arbeit mehr zu erledigen hat (wenn ein Wert zur\u00fcckgegeben wird, hat es die Berechnung abgeschlossen) oder wenn “au\u00dfergew\u00f6hnliche” Umst\u00e4nde aufgetreten sind, die verhindern, dass es fortgesetzt wird, und daher erforderlich sind Ausnahmebehandlung.Das h\u00e4ufigste Problem beim vorzeitigen Beenden besteht darin, dass Bereinigungs- oder Abschlussanweisungen nicht ausgef\u00fchrt werden. Beispielsweise wird der zugewiesene Speicher nicht freigegeben oder offene Dateien werden nicht geschlossen, was zu Speicher- oder Ressourcenlecks f\u00fchrt.  Diese m\u00fcssen an jeder R\u00fcckgabestelle durchgef\u00fchrt werden, die spr\u00f6de ist und leicht zu Fehlern f\u00fchren kann.  Beispielsweise k\u00f6nnte in einer sp\u00e4teren Entwicklung eine return-Anweisung von einem Entwickler \u00fcbersehen werden, und eine Aktion, die am Ende einer Unterroutine ausgef\u00fchrt werden sollte (z. B. eine Trace-Anweisung), wird m\u00f6glicherweise nicht in allen F\u00e4llen ausgef\u00fchrt.  Sprachen ohne return-Anweisung wie Standard Pascal und Seed7 haben dieses Problem nicht.Die meisten modernen Sprachen bieten Unterst\u00fctzung auf Sprachebene, um solche Lecks zu verhindern.  Siehe ausf\u00fchrliche Diskussion unter Ressourcenmanagement.  Am h\u00e4ufigsten erfolgt dies \u00fcber einen Abwicklungsschutz, der sicherstellt, dass bestimmte Codes garantiert ausgef\u00fchrt werden, wenn die Ausf\u00fchrung einen Block verl\u00e4sst.  Dies ist eine strukturierte Alternative zu einem Bereinigungsblock und einem goto.  Dies ist am h\u00e4ufigsten bekannt als try...finally, und als Teil der Ausnahmebehandlung betrachtet.  Bei mehreren return einleitende Aussagen try...finally, ohne Ausnahmen k\u00f6nnte seltsam aussehen.  Es gibt verschiedene Techniken, um das Ressourcenmanagement zu kapseln.  Ein alternativer Ansatz, der haupts\u00e4chlich in C ++ zu finden ist, ist Resource Acquisition Is Initialization, bei dem das normale Abwickeln des Stapels (variable Freigabe) beim Beenden der Funktion verwendet wird, um Destruktoren f\u00fcr lokale Variablen aufzurufen, um die Freigabe von Ressourcen aufzuheben.Kent Beck, Martin Fowler und Co-Autoren haben in ihren Refactoring-B\u00fcchern argumentiert, dass verschachtelte Bedingungen m\u00f6glicherweise schwerer zu verstehen sind als eine bestimmte Art von flacherer Struktur, wenn mehrere Ausg\u00e4nge verwendet werden, die durch Schutzklauseln vorhergesagt werden.  In ihrem Buch von 2009 hei\u00dft es rundweg: “Ein Austrittspunkt ist wirklich keine n\u00fctzliche Regel. Klarheit ist das Schl\u00fcsselprinzip: Wenn die Methode mit einem Austrittspunkt klarer ist, verwenden Sie einen Austrittspunkt, andernfalls nicht.”  Sie bieten eine Kochbuchl\u00f6sung zum Umwandeln einer Funktion, die nur aus verschachtelten Bedingungen besteht, in eine Folge von gesch\u00fctzten R\u00fcckgabeanweisungen (oder Wurfanweisungen), gefolgt von einem einzelnen unbewachten Block, der den Code f\u00fcr den allgemeinen Fall enthalten soll, w\u00e4hrend die gesch\u00fctzten Anweisungen sind soll mit den weniger h\u00e4ufigen (oder mit Fehlern) umgehen.[9]Herb Sutter und Andrei Alexandrescu argumentieren in ihrem C ++ – Tippbuch von 2004 auch, dass der Single-Exit-Punkt eine veraltete Anforderung ist.[10]In seinem Lehrbuch von 2004 schreibt David Watt, dass “Kontrollfl\u00fcsse mit einem Eingang und mehreren Ausg\u00e4ngen oft w\u00fcnschenswert sind”.  Unter Verwendung von Tennents Framework-Konzept des Sequenzierers beschreibt Watt einheitlich die Kontrollflusskonstrukte, die in modernen Programmiersprachen zu finden sind, und versucht zu erkl\u00e4ren, warum bestimmte Arten von Sequenzern im Kontext von Kontrollfl\u00fcssen mit mehreren Ausg\u00e4ngen anderen vorzuziehen sind.  Watt schreibt, dass uneingeschr\u00e4nkte Gotos (Sprungsequenzierer) schlecht sind, weil das Ziel des Sprunges f\u00fcr den Leser eines Programms nicht selbsterkl\u00e4rend ist, bis der Leser das tats\u00e4chliche Etikett oder die Adresse findet und untersucht, die das Ziel des Sprunges ist.  Im Gegensatz dazu argumentiert Watt, dass die konzeptionelle Absicht eines Return-Sequenzers aus seinem eigenen Kontext klar hervorgeht, ohne dass sein Ziel untersucht werden muss.  Watt schreibt, dass eine Klasse von Sequenzern bekannt als Escape-Sequenzer, definiert als “Sequenzer, der die Ausf\u00fchrung eines textumschlie\u00dfenden Befehls oder einer Prozedur beendet”, umfasst sowohl Unterbrechungen von Schleifen (einschlie\u00dflich mehrstufiger Unterbrechungen) als auch return-Anweisungen.  Watt merkt auch an, dass Sprungsequenzer (gotos) in Sprachen wie C, in denen das Ziel ein innerhalb des lokalen Blocks oder ein umfassender \u00e4u\u00dferer Block sein muss, etwas eingeschr\u00e4nkt waren, diese Einschr\u00e4nkung allein jedoch nicht ausreicht, um die Absicht von gotos in C self zu machen -beschreibend und so k\u00f6nnen sie immer noch “Spaghetti-Code” produzieren.  Watt untersucht auch, wie sich Ausnahme-Sequenzer von Flucht- und Sprung-Sequenzern unterscheiden.  Dies wird im n\u00e4chsten Abschnitt dieses Artikels erl\u00e4utert.[11]Im Gegensatz dazu schrieb Bertrand Meyer in seinem Lehrbuch 2009, dass Anweisungen wie break und continue “sind nur die alten goto im Schafspelz “und dringend von ihrer Verwendung abgeraten.[12]Ausnahmebehandlung[edit]Basierend auf dem Codierungsfehler der Ariane 501-Katastrophe argumentiert der Softwareentwickler Jim Bonang, dass alle von einer Funktion ausgel\u00f6sten Ausnahmen das Single-Exit-Paradigma verletzen, und schl\u00e4gt vor, alle prozeduralen Ausnahmen zu verbieten.  In der C ++ – Syntax erfolgt dies, indem alle Funktionssignaturen als deklariert werden noexcept (seit C ++ 11) oder throw().[13]  Bonang schl\u00e4gt vor, dass alle Single-Exit-konformen C ++ wie folgt geschrieben werden sollten:bool MyCheck1() throw() {  bool success = false;  try {    \/\/ Do something that may throw exceptions.    if (!MyCheck2()) {      throw SomeInternalException();    }    \/\/ Other code similar to the above.    success = true;  } catch (...) {    \/\/ All exceptions caught and logged.  }  return success;}Peter Ritchie merkt auch an, dass im Prinzip sogar eine einzige throw kurz vor dem return in einer Funktion stellt eine Verletzung des Single-Exit-Prinzips dar, argumentiert jedoch, dass Dijkstras Regeln in einer Zeit geschrieben wurden, bevor die Ausnahmebehandlung zu einem Paradigma in Programmiersprachen wurde, und schl\u00e4gt daher vor, zus\u00e4tzlich zu einem einzelnen R\u00fcckgabepunkt eine beliebige Anzahl von Wurfpunkten zuzulassen .  Er stellt fest, dass L\u00f6sungen, die Ausnahmen umschlie\u00dfen, um einen Single-Exit zu erstellen, eine h\u00f6here Verschachtelungstiefe aufweisen und daher schwieriger zu verstehen sind, und beschuldigt sogar diejenigen, die vorschlagen, solche L\u00f6sungen auf Programmiersprachen anzuwenden, die Ausnahmen des Frachtkultdenkens unterst\u00fctzen .[14]David Watt analysiert auch die Ausnahmebehandlung im Rahmen von Sequenzern (in diesem Artikel im vorherigen Abschnitt zu fr\u00fchen Exits vorgestellt). Watt stellt fest, dass eine abnormale Situation (im Allgemeinen veranschaulicht durch arithmetische \u00dcberl\u00e4ufe oder Eingabe- \/ Ausgabefehler wie Datei nicht gefunden) eine Art ist Fehler, dass “in einer Low-Level-Programmeinheit erkannt wird, aber [for which] Ein Handler befindet sich nat\u00fcrlicher in einer \u00fcbergeordneten Programmeinheit. “Ein Programm kann beispielsweise mehrere Aufrufe zum Lesen von Dateien enthalten. Die auszuf\u00fchrende Aktion, wenn eine Datei nicht gefunden wird, h\u00e4ngt jedoch von der Bedeutung (dem Zweck) der Datei in ab Eine Frage an das Programm und damit eine Handhabungsroutine f\u00fcr diese abnormale Situation kann nicht im Systemcode auf niedriger Ebene gefunden werden. Watts stellt ferner fest, dass das Einf\u00fchren von Statusflags-Tests im Aufrufer als strukturierte Single-Exit-Programmierung oder sogar (Multi-Exit-) Return-Sequenzer Dies w\u00fcrde dazu f\u00fchren, dass “der Anwendungscode durch Tests von Statusflags un\u00fcbersichtlich wird” und “der Programmierer das Testen eines Statusflags m\u00f6glicherweise vergesslich oder tr\u00e4ge unterl\u00e4sst.  In der Tat werden abnormale Situationen, die durch Statusflags dargestellt werden, standardm\u00e4\u00dfig ignoriert! “Er stellt fest, dass Ausnahmen im Gegensatz zum Testen von Statusflags das entgegengesetzte Standardverhalten aufweisen und dazu f\u00fchren, dass das Programm beendet wird, es sei denn, der Programmierer behandelt die Ausnahme m\u00f6glicherweise explizit auf irgendeine Weise Durch Hinzuf\u00fcgen von Code, um ihn absichtlich zu ignorieren. Basierend auf diesen Argumenten kommt Watt zu dem Schluss, dass Sprungsequenzierer oder Escape-Sequenzer (im vorherigen Abschnitt beschrieben) nicht so geeignet sind wie ein dedizierter Ausnahmesequenzer mit der oben diskutierten Semantik.[15]Das Lehrbuch von Louden und Lambert betont, dass sich die Ausnahmebehandlung von strukturierten Programmierkonstrukten wie unterscheidet while Schleifen, weil die \u00dcbertragung der Kontrolle “an einem anderen Punkt im Programm eingerichtet ist als an dem Punkt, an dem die eigentliche \u00dcbertragung stattfindet. An dem Punkt, an dem die \u00dcbertragung tats\u00e4chlich stattfindet, gibt es m\u00f6glicherweise keinen syntaktischen Hinweis darauf, dass die Kontrolle tats\u00e4chlich \u00fcbertragen wird.”[16]  Der Informatikprofessor Arvind Kumar Bansal merkt auch an, dass in Sprachen, die Ausnahmebehandlung implementieren, sogar Kontrollstrukturen wie for, die die Single-Exit-Eigenschaft in Abwesenheit von Ausnahmen haben, haben sie nicht mehr in Gegenwart von Ausnahmen, da eine Ausnahme einen vorzeitigen Exit in irgendeinem Teil der Kontrollstruktur verursachen kann;  zum Beispiel wenn init() l\u00f6st eine Ausnahme aus for (init(); check(); increm()), dann ist der \u00fcbliche Austrittspunkt nach check () nicht erreicht.[17]  Westley Weimer und George Necula zitierten mehrere fr\u00fchere Studien anderer (1999-2004) und ihre eigenen Ergebnisse und schrieben, dass ein bedeutendes Problem mit Ausnahmen darin besteht, dass sie “versteckte Kontrollflusspfade schaffen, \u00fcber die Programmierer nur schwer nachdenken k\u00f6nnen”.[18]::8:27Die Notwendigkeit, Code auf Single-Exit-Punkte zu beschr\u00e4nken, tritt in einigen modernen Programmierumgebungen auf, die sich auf paralleles Rechnen konzentrieren, wie z. B. OpenMP.  Die verschiedenen parallelen Konstrukte von OpenMP m\u00f6gen parallel doLassen Sie keine vorzeitigen Austritte von innen nach au\u00dfen des parallelen Konstrukts zu.  Diese Einschr\u00e4nkung umfasst alle Arten von Ausg\u00e4ngen von break zu C ++ – Ausnahmen, aber alle diese sind innerhalb des parallelen Konstrukts zul\u00e4ssig, wenn sich das Sprungziel auch darin befindet.[19]Mehrfacheintrag[edit]Seltener erlauben Unterprogramme mehrere Eintrag. Dies ist am h\u00e4ufigsten nur Re-Eintrag in eine Coroutine (oder Generator \/ Semicoroutine), in der ein Unterprogramm die Kontrolle (und m\u00f6glicherweise einen Wert) liefert, aber dann dort fortgesetzt werden kann, wo es aufgeh\u00f6rt hat.  Es gibt eine Reihe g\u00e4ngiger Anwendungen dieser Programmierung, insbesondere f\u00fcr Streams (insbesondere Eingabe \/ Ausgabe), Zustandsautomaten und Parallelit\u00e4t.  Unter dem Gesichtspunkt der Codeausf\u00fchrung ist das Nachgeben einer Coroutine n\u00e4her an der strukturierten Programmierung als das Zur\u00fcckgeben von einer Unterroutine, da das Unterprogramm nicht tats\u00e4chlich beendet wurde und beim erneuten Aufruf fortgesetzt wird – es ist kein vorzeitiger Exit.  Coroutinen bedeuten jedoch, dass mehrere Unterprogramme einen Ausf\u00fchrungsstatus haben – und nicht einen einzelnen Aufrufstapel von Unterroutinen – und somit eine andere Form der Komplexit\u00e4t einf\u00fchren.Es ist sehr selten, dass Unterprogramme die Eingabe einer beliebigen Position im Unterprogramm erm\u00f6glichen, da in diesem Fall der Programmstatus (z. B. variable Werte) nicht initialisiert oder mehrdeutig ist und dies einem goto sehr \u00e4hnlich ist.Zustandsautomaten[edit]Einige Programme, insbesondere Parser und Kommunikationsprotokolle, haben eine Reihe von Zust\u00e4nden, die auf eine Weise aufeinander folgen, die sich nicht leicht auf die Grundstrukturen reduzieren l\u00e4sst, und einige Programmierer implementieren die Zustands\u00e4nderungen mit einem Sprung in den neuen Zustand.  Diese Art der Statusumschaltung wird h\u00e4ufig im Linux-Kernel verwendet.[citation needed]Es ist jedoch m\u00f6glich, diese Systeme zu strukturieren, indem jede Zustands\u00e4nderung zu einem eigenen Unterprogramm gemacht wird und eine Variable verwendet wird, um den aktiven Zustand anzuzeigen (siehe Trampolin).  Alternativ k\u00f6nnen diese \u00fcber Coroutinen implementiert werden, die auf das Trampolin verzichten.Siehe auch[edit]Verweise[edit]Zitate[edit]^ Clark, Leslie B. Wilson, Robert G.;  Robert, Clark (2000). Vergleichende Programmiersprachen  (3. Aufl.).  Harlow, England: Addison-Wesley.  p.  20. ISBN 9780201710120. Archiviert vom Original am 26. November 2015.  Abgerufen 25. November 2015.^ B\u00f6hm, Corrado;  Giuseppe Jacopini (Mai 1966). “Flussdiagramme, Turingmaschinen und Sprachen mit nur zwei Formationsregeln” (PDF). Mitteilungen der ACM. 9 (5): 366\u2013371.  CiteSeerX 10.1.1.119.9119.  doi:10.1145 \/ 355592.365646.  S2CID 10236439. Archiviert (PDF) vom Original am 23.09.2015.^ Dijkstra, EW (M\u00e4rz 1968).  “Briefe an den Herausgeber: Zur Erkl\u00e4rung gehen, die als sch\u00e4dlich angesehen wird”. Mitteilungen der ACM. 11 (3): 147\u2013148.  doi:10.1145 \/ 362929.362947.  ISSN 0001-0782.  S2CID 17469809.^ Plauger, PJ (12. Februar 1993). Zweckm\u00e4\u00dfiges Programmieren, Aufs\u00e4tze zum Software-Design  (1 ed.).  Prentice-Hall.  p. 25.  ISBN 978-0-13-721374-0.^ Donald Knuth – Strukturierte Programmierung mit go to Anweisungen Archiviert 23.10.2013 an der Wayback-Maschine^ Frank Rubin (M\u00e4rz 1987). “”“”GOTO als sch\u00e4dlich eingestuft “als sch\u00e4dlich eingestuft” (PDF). Mitteilungen der ACM. 30 (3): 195\u2013196.  doi:10.1145 \/ 214748.315722.  S2CID 6853038.  Archiviert von das Original (PDF) am 20.03.2009.^ Jay Fields;  Shane Harvie;  Martin Fowler;  Kent Beck (2009). Refactoring: Ruby Edition.  Pearson Ausbildung.  S. 274\u2013279.  ISBN 978-0-321-60350-0.^ Herb Sutter;  Andrei Alexandrescu (2004). C ++ – Codierungsstandards: 101 Regeln, Richtlinien und Best Practices.  Pearson Ausbildung.  ISBN 978-0-13-265442-5. “Beispiel 4: Einzeleintrag, Einzelausgang (” SESE “). In der Vergangenheit haben einige Codierungsstandards verlangt, dass jede Funktion genau einen Ausgang hat, was eine R\u00fcckgabeanweisung bedeutet. Eine solche Anforderung ist in Sprachen, die Ausnahmen und Destruktoren unterst\u00fctzen, in denen Funktionen \u00fcberholt sind haben normalerweise zahlreiche implizite Ausg\u00e4nge. “)^ David Anthony Watt;  William Findlay (2004). Designkonzepte f\u00fcr Programmiersprachen.  John Wiley & Sons.  S. 215\u2013221.  ISBN 978-0-470-85320-7.^ Bertrand Meyer (2009). Touch of Class: Lernen, mit Objekten und Vertr\u00e4gen gut zu programmieren.  Springer Science & Business Media.  p.  189. ISBN 978-3-540-92144-8.^ “PragPub April 2012 – Die pragmatische Verteidigung – Das pragmatische B\u00fccherregal”. pragprog.com. Archiviert vom Original am 10. Juli 2017.  Abgerufen 6. Mai 2018.^ “Single-Entry, Single-Exit, sollte es in objektorientierten Sprachen noch anwendbar sein? – Peter Ritchies MVP-Blog”. Archiviert vom Original am 14.11.2012.  Abgerufen 2014-07-15.^ David Anthony Watt;  William Findlay (2004). Designkonzepte f\u00fcr Programmiersprachen.  John Wiley & Sons.  S. 221\u2013222.  ISBN 978-0-470-85320-7.^ Kenneth C. Louden;  Kenneth A. Lambert (2011). Programmiersprachen: Prinzipien und Praktiken (3. Aufl.).  Lernen einbinden.  p.  423. ISBN 978-1-111-52941-3.^ Arvind Kumar Bansal (2013). Einf\u00fchrung in Programmiersprachen.  CRC Dr\u00fccken Sie.  p.  135. ISBN 978-1-4665-6514-2.^ Weimer, W & Necula, GC (2008). “Au\u00dfergew\u00f6hnliche Situationen und Programmzuverl\u00e4ssigkeit” (PDF). ACM-Transaktionen zu Programmiersprachen und -systemen. 30 (2). Archiviert (PDF) vom Original am 23.09.2015.^ Rohit Chandra (2001). Parallele Programmierung in OpenMP.  Morgan Kaufmann.  p.  45. ISBN 978-1-55860-671-5.Quellen[edit]Edsger Dijkstra, Hinweise zur strukturierten Programmierung, p.  6.B\u00f6hm, C.;  Jacopini, G. (Mai 1966). “Flussdiagramme, Turingmaschinen und Sprachen mit nur zwei Formationsregeln” (PDF). Mitteilungen der ACM. 9 (5): 366\u2013371.  CiteSeerX 10.1.1.119.9119.  doi:10.1145 \/ 355592.365646.  S2CID 10236439.Dijkstra, Edsger W. (M\u00e4rz 1968). “Briefe an den Herausgeber: Zur Erkl\u00e4rung gehen, die als sch\u00e4dlich angesehen wird” (PDF). Mitteilungen der ACM. 11 (3): 147\u2013148.  doi:10.1145 \/ 362929.362947.  S2CID 17469809.Michael A. Jackson, Prinzipien der Programmgestaltung, Academic Press, London, 1975.O.-J.  Dahl, EW Dijkstra, CAR Hoare Strukturierte Programmierung, Academic Press, London, 1972. ISBN 0-12-200550-3.Dieser Band enth\u00e4lt eine erweiterte Version des Hinweise zur strukturierten Programmierung, einschlie\u00dflich eines erweiterten Beispiels f\u00fcr die Verwendung des strukturierten Ansatzes zur Entwicklung eines Backtracking-Algorithmus zur L\u00f6sung des 8 Queens-Problems.Eine PDF-Version befindet sich in der ACM Classic Books-ReiheBeachten Sie, dass das dritte Kapitel dieses Buches von Dahl einen Ansatz beschreibt, der leicht als objektorientierte Programmierung erkannt werden kann.  Es kann als eine andere M\u00f6glichkeit angesehen werden, ein Programm “sinnvoll zu strukturieren”, um zu zeigen, dass es korrekt ist.Elder, Matt;  Jackson, Steve;  Liblit, Ben (Oktober 2008). Code Sandwiches (PDF) (Technischer Bericht).  Universit\u00e4t von Wisconsin-Madison.  1647, abstraktExterne Links[edit]BPStruct – Ein Werkzeug zur Strukturierung gleichzeitiger Systeme (Programme, Prozessmodelle)J. Darlinton;  M. Ghanem;  HW To (1993), “Structured Parallel Programming”, In Programmiermodellen f\u00fcr massiv parallele Computer.  IEEE Computer Society Press.  1993: 160\u2013169, CiteSeerX 10.1.1.37.4610"},{"@context":"http:\/\/schema.org\/","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"https:\/\/wiki.edu.vn\/wiki16\/#breadcrumbitem","name":"Enzyklop\u00e4die"}},{"@type":"ListItem","position":2,"item":{"@id":"https:\/\/wiki.edu.vn\/wiki16\/2021\/01\/22\/strukturierte-programmierung-wikipedia\/#breadcrumbitem","name":"Strukturierte Programmierung – Wikipedia"}}]}]