Strukturierte Programmierung

Strukturierte Programmierung ist ein Programmierparadigma Ziel, die Klarheit, Qualität und Entwicklungszeit von a zu verbessern Computer Programm durch umfassende Verwendung der strukturierten Kontrollflusskonstrukte der Auswahl (wenn/dann/sonst) und Wiederholung (während und zum), Blockstrukturen, und Unterroutinen.

Es entstand in den späten 1950er Jahren mit dem Aussehen der Algol 58 und Algol 60 Programmiersprachen,[1] mit letzterem einschließlich der Unterstützung für Blockstrukturen. Zuerst in der Wissenschaft und später unter den Praktikern beiträgt die Faktoren zu seiner Popularität und weit verbreiteten Akzeptanz bei Strukturierter Programm Theorem 1966,,[2] und die Veröffentlichung des einflussreichen "Gehen Sie zu einer schädlichen Aussage als schädlich"Open Letter im Jahr 1968 durch niederländische Informatiker Edsger W. Dijkstra, der den Begriff "strukturiertes Programmieren" geprägt hat.[3]

Strukturierte Programmierung wird am häufigsten mit Abweichungen verwendet, die in bestimmten Fällen klarere Programme ermöglichen, z. B. wann Ausnahmebehandlung muss durchgeführt werden.

Elemente

Kontrollstrukturen

Folgt dem Strukturierter Programm Theorem, alle Programme werden als zusammengesetzt aus Kontrollstrukturen:

  • "Reihenfolge"; Bestellte Aussagen oder Unterprogramme, die nacheinander ausgeführt werden.
  • "Auswahl"; Eine oder eine Reihe von Aussagen wird je nach Status des Programms ausgeführt. Dies wird normalerweise mit ausgedrückt mit Schlüsselwörter wie zum Beispiel Wenn.. dann..else..endif. Die bedingte Aussage sollte mindestens einen echten Zustand haben und jede Bedingung sollte einen Ausgangspunkt bei max.
  • "Wiederholung"; Eine Erklärung oder ein Block wird ausgeführt, bis das Programm einen bestimmten Zustand erreicht oder Operationen auf jedes Element einer Sammlung angewendet wurden. Dies wird normalerweise mit Schlüsselwörtern ausgedrückt, z. während, wiederholen, zum oder machen bis. Oft wird empfohlen, dass jede Schleife nur einen Einstiegspunkt haben sollte (und in der ursprünglichen strukturellen Programmierung auch nur einen Ausstiegspunkt, und einige Sprachen erzwingen dies).
  • "Rekursion"; Eine Erklärung wird ausgeführt, indem Sie sich wiederholt anrufen, bis die Kündigungsbedingungen erfüllt sind. In der Praxis wie iterativen Schleifen ähnlich, sind rekursive Schleifen möglicherweise rechnerischer und werden als Kaskadierungsstapel unterschiedlich implementiert.
Grafische Darstellung der Drei grundlegende Muster - Sequenz, Selektion und Wiederholung - Verwenden NS -Diagramme (blau) und Flussdiagramme (grün).

Unterroutinen

Unterroutinen; Callable -Einheiten wie Verfahren, Funktionen, Methoden oder Unterprogramme werden verwendet, um eine Sequenz durch eine einzelne Anweisung zu ermöglichen.

Blöcke

Blöcke werden verwendet, um es zu ermöglichen, Gruppen von Aussagen so zu behandeln, als wären sie eine Aussage. Blockstrukturiert Sprachen haben eine Syntax, um Strukturen auf formelle Weise einzuschließen, z. Wenn..fi wie in Algol 68, oder ein Code -Abschnitt, der von festgehalten wird Beginnen Sie, wie in Pl/i und Pascal, Whitespace Eindrückung wie in Python, oder die lockigen Zahnspangen {...} von C und viele spätere Sprachen.

Strukturierte Programmiersprachen

Es ist möglich, strukturierte Programmierung in jeder Programmiersprache durchzuführen, obwohl es vorzuziehen ist, so etwas wie a zu verwenden prozedurale Programmiersprache.[Klarstellung erforderlich] Einige der ursprünglich für strukturierten Programmierungen verwendeten Sprachen umfassen: Algol, Pascal, Pl/i und AdaAber die meisten neuen prozeduralen Programmiersprachen seit dieser Zeit haben Funktionen zur Förderung strukturierter Programmierung und manchmal absichtlich ausgelassen - insbesondere Goto -, um zu machen unstrukturierte Programmierung schwieriger.Strukturierte Programmierung (Manchmal als modulares Programmieren bezeichnet) erzwingt eine logische Struktur des Programms, die geschrieben wird, um es effizienter und einfacher zu verstehen und zu ändern.

Geschichte

Theoretische Grundlage

Das Strukturierter Programm Theorem Bietet die theoretische Grundlage der strukturierten Programmierung. Es heißt, dass drei Möglichkeiten zur Kombination von Programmen - Sequencing, Selektion und Iteration - ausreichen, um alle auszudrücken berechnungsbare Funktion. Diese Beobachtung stammte nicht mit der strukturierten Programmierbewegung; Diese Strukturen reichen aus, um die zu beschreiben Anweisungszyklus von a Zentrale Verarbeitungseinheitsowie der Betrieb von a Turing Maschine. Daher führt ein Prozessor in diesem Sinne immer ein "strukturiertes Programm" aus, auch wenn die von ihm gelesenen Anweisungen nicht Teil eines strukturierten Programms sind. Autoren würdigen das Ergebnis jedoch in der Regel einem Papier von Böhm und Jacopini von 1966, möglicherweise weil Dijkstra zitierte dieses Papier selbst.[4] Der strukturierte Programmsatz befasst sich nicht mit dem Schreiben und Analysieren eines nützlich strukturierten Programms. Diese Probleme wurden in den späten 1960er und frühen 1970er Jahren mit wichtigen Beiträgen von angegangen Dijkstra, Robert W. Floyd, Tony Hoare, Ole-Johan Dahl, und David Gries.

Debatte

P. J. Plauger, ein frühzeitiger Anwender der strukturierten Programmierung beschrieben seine Reaktion auf den strukturierten Programmsatz:

Wir konvertierten diese interessanten Neuigkeiten unter den Nasen der nicht rekonstruierten Programmierer, die immer wieder verdrehte Logikstücke hervorbrachten, und sagte: "Ich wette, ich kann das nicht strukturieren." Weder der Beweis von Böhm und Jacopini noch unsere wiederholten Erfolge beim Schreiben strukturierter Code brachten sie einen Tag früher, als sie bereit waren, sich selbst zu überzeugen.[5]

Donald Knuth Akzeptierte das Prinzip, dass Programme unter Berücksichtigung von Vorbereitung geschrieben werden müssen, aber er war nicht einverstanden, die GOTO -Erklärung abzuschaffen, und hat es ab 2018 weiterhin in seinen Programmen verwendet.[6] In seinem 1974er Artikel "strukturiertes Programmieren mit GOTO -Aussagen",[7] Er gab Beispiele, bei denen er glaubte, dass ein direkter Sprung zu klareren und effizienteren Code führt, ohne die Bekanntheit zu beeinträchtigen. Knuth schlug eine lockere strukturelle Einschränkung vor: Es sollte möglich sein, das Programm zu zeichnen Flussdiagramm Mit allen Vorwärtsästen links, alle rückwärts gerichteten Zweige und keine Zweige, die sich gegenseitig überqueren. Viele von denen, die sich auskundigen Compiler und Graphentheorie befürwortet nur zuzulassen Reduzierbare Durchflussdiagramme[wenn definiert als?].[wer?]

Strukturierte Programmiertheoretiker erlangten in den 1970er Jahren einen großen Verbündeten IBM Forscher Harlan Mills angewendet seine Interpretation der strukturierten Programmierungstheorie auf die Entwicklung eines Indexierungssystems für Die New York Times Forschungsdatei. Das Projekt war ein großartiger Ingenieurerfolg, und die Manager von anderen Unternehmen zitierten es zur Unterstützung der Einführung strukturierter Programmierung, obwohl Dijkstra die Art und Weise kritisierte, wie die Interpretation von Mills von den veröffentlichten Arbeiten unterschiedlich war.

Noch 1987 war es immer noch möglich, die Frage der strukturierten Programmierung in einem Informatikjournal aufzuwerfen. Frank Rubin tat dies in diesem Jahr mit einem offenen Brief mit dem Titel "Goto gilt als schädlich als schädlich.[8] Es folgten zahlreiche Einwände, darunter eine Antwort von Dijkstra, die sowohl Rubin als auch die Zugeständnisse, die andere Autoren machten, bei der Reaktion auf ihn stark kritisierte.

Ergebnis

Bis zum Ende des 20. Jahrhunderts waren fast alle Informatiker davon überzeugt, dass es nützlich ist, die Konzepte der strukturierten Programmierung zu lernen und anzuwenden. Hochrangige Programmiersprachen, denen ursprünglich Programmierstrukturen nicht mehr fehlten, wie z. Forran, Cobol, und BASIC, jetzt haben sie.

Gemeinsame Abweichungen

Während GOTO nun größtenteils durch die strukturierten Auswahlkonstrukte (wenn/dann/sonst) und die Wiederholung (während und für) ersetzt wurde, sind nur wenige Sprachen rein strukturiert. Die häufigste Abweichung, die in vielen Sprachen vorkommt, ist die Verwendung von a Rückgabeerklärung Für einen frühen Ausstieg aus einem Unterprogramm. Dies führt zu mehreren Exit -Punkten anstelle des einzelnen Ausgangspunkts, der durch strukturierte Programmierung erforderlich ist. Es gibt andere Konstruktionen, um Fälle zu bewältigen, die bei rein strukturiertem Programmieren unangenehm sind.

Früher Ausgang

Die häufigste Abweichung von der strukturierten Programmierung ist der frühe Ausgang einer Funktion oder Schleife. Auf der Ebene der Funktionen ist dies a Rückkehr Aussage. Auf der Ebene der Schleifen ist dies a Unterbrechung Anweisung (Beendigung der Schleife) oder fortsetzen Erklärung (Beenden Sie die aktuelle Iteration, fahren Sie mit der nächsten Iteration fort). Bei der strukturierten Programmierung können diese durch Hinzufügen zusätzlicher Zweige oder Tests repliziert werden. Für Rückgaben aus dem verschachtelten Code kann dies jedoch erhebliche Komplexität hinzufügen. C ist ein frühes und herausragendes Beispiel für diese Konstrukte. Einige neuere Sprachen haben auch "beschriftete Pausen", die es ermöglichen, mehr als nur die innerste Schleife auszubrechen. Ausnahmen ermöglichen auch einen frühen Ausstieg, haben jedoch weitere Konsequenzen und werden daher unten behandelt.

Mehrere Ausgänge können aus einer Vielzahl von Gründen entstehen, meistens entweder die Unterroutine nicht mehr zu tun (wenn sie einen Wert zurückgibt, hat die Berechnung abgeschlossen) oder hat "außergewöhnliche" Umstände gestoßen Ausnahmebehandlung.

Das häufigste Problem beim frühen Ausgang ist, dass die Aufräumarbeiten oder die endgültigen Aussagen nicht ausgeführt werden - zum Beispiel wird der zugewiesene Speicher nicht verhandelt, oder offene Dateien sind nicht geschlossen, was verursacht wird Speicherlecks oder Ressourcenlecks. Diese müssen an jeder Rückkehrort erfolgen, die spröde ist und leicht zu Fehlern führen kann. In späterer Entwicklung könnte beispielsweise eine Return -Erklärung von einem Entwickler und eine Aktion übersehen werden, die am Ende eines Unterroutine ausgeführt werden sollte (z. B. a verfolgen Aussage) wird möglicherweise nicht in allen Fällen durchgeführt. Sprachen ohne Rückgabeerklärung wie Standard Pascal und Samen7Haben Sie dieses Problem nicht.

Die meisten modernen Sprachen bieten Unterstützung auf Sprachebene, um solche Lecks zu verhindern.[9] Siehe detaillierte Diskussion unter Resourcenmanagement. Am häufigsten erfolgt dies durch Abwicklungsschutz, was sicherstellt, dass ein bestimmter Code garantiert ausgeführt wird, wenn die Ausführung einen Block verlässt. Dies ist eine strukturierte Alternative zu einem Reinigungsblock und a gehe zu. Dies ist am häufigsten als bekannt als versuche ... endlich, und als Teil von angesehen Ausnahmebehandlung. Im Falle von mehreren Rückkehr Aussagen einführen versuche ... endlich, Ohne Ausnahmen könnten seltsam aussehen. Es gibt verschiedene Techniken, um das Ressourcenmanagement zu verkörpern. Ein alternativer Ansatz, der hauptsächlich in C ++ vorkommt, ist Ressourcenerwerb ist die Initialisierung, bei der normale Stapelabwicklung (variable Deallocation) am Funktionsaustritt zum Aufrufen von Destruktoren in lokalen Variablen zur Deposition von Ressourcen verwendet wird.

Kent Beck, Martin Fowler und Co-Autoren haben in ihren argumentiert Refactoring Bücher, die verschachtelte Bedingungen möglicherweise schwerer zu verstehen sind als eine bestimmte Art von flacher Struktur unter Verwendung mehrerer Ausgänge, die von beruht werden Wachklauseln. In ihrem 2009er Buch heißt es rundheraus, dass "ein Ausstiegspunkt wirklich keine nützliche Regel ist. Klarheit ist das Schlüsselprinzip: Wenn die Methode mit einem Ausstiegspunkt klarer ist, verwenden Sie einen Ausstiegspunkt; sonst nicht". Sie bieten eine Kochbuchlösung für die Umwandlung einer Funktion, die nur aus verschachtelten Bedingungen in eine Abfolge von geschützten Rückkehr- (oder Wurf-) Aussagen besteht, gefolgt von einem einzelnen unbewachten Block, der den Code für den gemeinsamen Fall enthalten soll, während die bewachten Anweisungen sind Soll mit den seltenen (oder mit Fehlern) umgehen.[10] Kräuter Sutter und Andrei Alexandrescu Argumentieren Sie auch in ihrem 2004 C ++-Tipps-Buch, dass der Einzel-Exit-Punkt eine veraltete Anforderung ist.[11]

In seinem Lehrbuch von 2004, David Watt schreibt, dass "Einzeleingangs-Kontrollflüsse oft wünschenswert sind". Verwenden von Tennents Framework -Begriff von Sequenzer, Watt beschreibt einheitlich die Kontrollflusskonstrukte in zeitgenössischen Programmiersprachen und Versuche zu erklären, warum bestimmte Arten von Sequenzern anderen im Kontext von Kontrollströmen mit mehreren Exits vorzuziehen sind. Watt schreibt, dass uneingeschränkte Gotos (Jump-Sequenzer) schlecht sind, weil das Ziel des Sprungs dem Leser eines Programms nicht selbsterklärend ist, bis der Leser das tatsächliche Etikett oder die richtige Adresse findet und untersucht, die das Ziel des Sprung ist. Im Gegensatz dazu argumentiert Watt, dass die konzeptionelle Absicht eines Rückfahrsequenzers aus seinem eigenen Kontext klar ist, ohne sein Ziel untersuchen zu müssen. Watt schreibt, dass eine Klasse von Sequenzern als als bekannt ist Fluchtsequenzer, definiert als "Sequenzer, der die Ausführung eines textuell einschließenden Befehls oder Verfahrens beendet", umfasst beide Pausen aus Schleifen (einschließlich Multi-Level-Pausen) und Rückgabeberichtungen. Watt merkt auch an, dass Jump -Sequenzer (Gotos) in Sprachen wie C etwas eingeschränkt wurden, wobei das Ziel ein innerhalb des lokalen Blocks oder ein umfassender äußerer Block sein muss, diese Einschränkung allein nicht ausreicht, um die Absicht von Gotos in C selbst zu machen -Beschreibe und so können sie immer noch produzieren "Spaghetti -Code". Watt untersucht auch, wie sich Ausnahmesequenzer von Escape- und Jump -Sequenzern unterscheiden. Dies wird im nächsten Abschnitt dieses Artikels erläutert.[12]

Im Gegensatz zum oben genannten, Bertrand Meyer schrieb in seinem Lehrbuch 2009, das Anweisungen mögen Unterbrechung und fortsetzen "Sind nur die alten gehe zu in Schafs Kleidung "und stark von ihrem Gebrauch geraten.[13]

Ausnahmebehandlung

Basierend auf dem Codierungsfehler aus dem Ariane 501 KatastropheDer Softwareentwickler Jim Bonang argumentiert, dass alle Ausnahmen aus einer Funktion gegen das Single-Exit-Paradigma verstoßen, und schlägt vor, dass alle interprozeduralen Ausnahmen verboten werden sollten. Bonang schlägt vor, dass alle Einzelexits C ++ entsprechend in den Zeilen geschrieben werden sollten:

bool MyCheck1() Wurf() {   bool Erfolg = FALSCH;   Versuchen {   // etwas tu etwas, das Ausnahmen veranstalten kann.   wenn (!MyCheck2()) {   Wurf EinigeInternalexception();   }   // Andere Code ähnlich dem oben genannten.   Erfolg = Stimmt;   } Fang (...) {   // Alle Ausnahmen gefangen und protokolliert.   }   Rückkehr Erfolg; }

Peter Ritchie merkt auch an, dass im Prinzip sogar eine einzige Wurf kurz vor dem Rückkehr In einer Funktion stellt ein Verstoß gegen das Prinzip der Einzelexit dar, argumentiert jedoch, dass die Regeln von Dijkstra in einer Zeit vor der Ausnahmeregelung geschrieben wurden . Er merkt an, dass Lösungen, die Ausnahmen für die Erstellung eines Einzelausgangs wickeln Frachtkult Denken.[14]

David Watt analysiert auch die Ausnahmebehandlung im Rahmen der Sequenzer (in diesem Artikel im vorherigen Abschnitt zu frühen Ausgängen eingeführt). Watt stellt fest Fehler, der "in einer Programmeinheit auf niedriger Ebene erkannt wird, aber für die ein Handler in einer hochrangigen Programmeinheit natürlicher ist". Beispielsweise kann ein Programm mehrere Anrufe zum Lesedateien enthalten, aber die Aktion, die ausgeführt werden soll, wenn eine Datei nicht gefunden wird befindet sich im Systemcode auf niedrigem Niveau. Watts stellt weiter fest, dass die Einführung von Statusflags im Anrufer als strukturierte Programmierung von Einzelaussagen oder sogar (Multi-Exit-) Rückgabesequenzer zu einer Situation führt, in der "der Anwendungscode dazu neigt, durch Tests von Status-Flags" und durch Tests von Status-Flags "und durch Tests von Status-Flags zu werden" und "und durch Tests von Status-Flags" und "und" der Anwendungscode tendiert dazu neigt, durch Tests von Status-Flags "und" und "und tendenziell durch Tests von Status-Flags" und "und" und tendenziell durch Tests von Status-Flags "und" und Dass "der Programmierer möglicherweise nachsichtlich oder faul wegweist, um eine Statusflagge zu testen. Tatsächlich werden abnormale Situationen, die durch Statusflags dargestellt werden, standardmäßig ignoriert!" Er merkt an, dass Ausnahmen im Gegensatz zu den Tests der Statusflags das Gegenteil haben Standardverhalten, was das Programm beendet, es sei denn, der Programmierer befasst sich explizit mit der Ausnahme in irgendeiner Weise, möglicherweise durch Hinzufügen von Code, um ihn absichtlich zu ignorieren. Basierend auf diesen Argumenten kommt Watt zu dem Schluss, dass Sprungsequenzer oder Escape -Sequenzer (im vorherigen Abschnitt diskutiert) nicht so geeignet sind wie ein dedizierter Ausnahmeberechnung mit der oben diskutierten Semantik.[15]

Das Lehrbuch von Louden und Lambert betont, dass die Ausnahmebehandlung sich von strukturierten Programmierkonstrukten wie unterscheidet wie während Schleifen Da der Kontrolltransfer "an einem anderen Punkt im Programm eingerichtet ist als das, wo die tatsächliche Übertragung stattfindet. An dem Punkt, an dem die Übertragung tatsächlich auftritt, gibt es möglicherweise keine syntaktische Anzeige, dass die Kontrolle tatsächlich übertragen wird."[16] Der Informatikprofessor Arvind Kumar Bansal stellt auch fest, dass in Sprachen, die Ausnahmebehandlung implementieren, sogar Strukturen wie zum, die die einzelne Exexit-Eigenschaft ohne Ausnahmen haben, haben sie nicht mehr in Gegenwart von Ausnahmen, da eine Ausnahme in einem Teil der Kontrollstruktur vorzeitig einen frühen Ausgang verursachen kann; Zum Beispiel wenn drin() wirft eine Ausnahme ein für (init (); check (); Increm ())und dann wird der übliche Ausstiegspunkt nach Check () nicht erreicht.[17] Unter Berufung auf mehrere frühere Studien von anderen (1999-2004) und ihre eigenen Ergebnisse, Westley Weimer und George Necula schrieb, dass ein erhebliches Problem mit Ausnahmen darin besteht, dass sie "versteckte Kontroll-Flow-Pfade erstellen, die für Programmierer schwierig sind, über die Argumentation zu argumentieren".[18]

Die Notwendigkeit, den Code auf Einzel-Exit-Punkte zu begrenzen OpenMP. Die verschiedenen parallelen Konstrukte von OpenMP, wie Parallele tunLassen Sie keine frühen Ausgänge von innen nach außen des parallelen Konstrukts; Diese Einschränkung umfasst alle Arten von Ausgängen aus, von Unterbrechung Zu C ++ - Ausnahmen, aber alle diese sind innerhalb des parallelen Konstrukts zulässig, wenn sich auch das Sprungziel darin befindet.[19]

Mehrfacheintrag

Weitere Informationen: Coroutine

Seltener erlauben Unterprogramme mehrere Eintrag. Dies ist am häufigsten nur betreffend-EN Sie in a Coroutine (oder Generator/semicoroutine), wo ein Subprogramm die Kontrolle (und möglicherweise einen Wert) ergibt, aber dann wieder aufgenommen werden kann, wo es aufgehört hat. Es gibt eine Reihe von gemeinsame Verwendungen von solchen Programmen, insbesondere für Ströme (insbesondere Eingabe/Ausgabe), Zustandsmaschinen und Parallelität. Aus Sicht der Codeausführung ist die Ausgabe aus einer Coroutine näher an der strukturierten Programmierung als die Rückkehr aus einer Unterprogramme, da das Subprogramm nicht tatsächlich beendet hat und wenn sie erneut aufgerufen wird - es ist kein früher Ausstieg. Coroutinen bedeuten jedoch, dass mehrere Unterprogramme Ausführungszustand - und nicht einen einzelnen Anrufstapel von Unterprogrammen - eine andere Form der Komplexität einführen.

Für Unterprogramme ist es sehr selten, den Eintritt in eine willkürliche Position im Subprogramm zu ermöglichen, wie in diesem Fall der Programmzustand (z. B. variable Werte) nicht initialisiert oder mehrdeutig, und dies ist einem GOTO sehr ähnlich.

Staatsmaschinen

Einige Programme, besonders Parser und Kommunikationsprotokolle, haben eine Reihe von Zustände Dies folgt einander auf eine Weise, die nicht leicht auf die grundlegenden Strukturen reduziert wird, und einige Programmierer implementieren die staatlichen Veränderungen mit einem Sprung in den neuen Staat. Diese Art von Zustandsschalter wird häufig im Linux-Kernel verwendet.

Es ist jedoch möglich, diese Systeme zu strukturieren, indem jeder Zustand zu einem separaten Unterprogramm und einer Variablen verwendet wird, um den aktiven Zustand anzuzeigen (siehe Trampolin). Alternativ können diese über Coroutinen implementiert werden, die auf das Trampolin abgeben.

Siehe auch

Verweise

Zitate

  1. ^ Clark, Leslie B. Wilson, Robert G.; Robert, Clark (2000). Vergleichende Programmiersprachen (3. Aufl.). Harlow, England: Addison-Wesley. p. 20. ISBN 9780201710120. Archiviert Aus dem Original am 26. November 2015. Abgerufen 25. November 2015.
  2. ^ Böhm & Jacopini 1966.
  3. ^ Dijkstra 1968, p. 147, "Die ungezügelte Verwendung der GO -to -Aussage hat eine unmittelbare Folge, dass es furchtbar schwierig wird, eine aussagekräftige Reihe von Koordinaten zu finden, um den Prozessfortschritt zu beschreiben. Es ist zu viel Einladung, um das eigene Programm durcheinander zu bringen. "
  4. ^ Dijkstra 1968.
  5. ^ Plauger, P. J. (12. Februar 1993). Absichtlich Programmierung, Essays zum Softwaredesign (1. Aufl.). Prentice-Hall. p.25. ISBN 978-0-13-721374-0.
  6. ^ DLS • Donald Knuth • Alle beantworteten Fragen. Youtube. Universität von Waterloo. 15. November 2018. 48 Minuten in. Abgerufen 24. Juli 2022.
  7. ^ Donald E. Knuth (Dezember 1974). "Strukturiertes Programmieren mit Go to Aussagen" (PDF). Computerumfragen. 6 (4): 261–301. doi:10.1145/356635.356640. S2CID 207630080. Archiviert von das Original (PDF) Am 2013-10-23.
  8. ^ Frank Rubin (März 1987). ""Goto gilt als schädlich als schädlich angesehen" (PDF). Kommunikation der ACM. 30 (3): 195–196. doi:10.1145/214748.315722. S2CID 6853038. Archiviert von das Original (PDF) am 2009-03-20.
  9. ^ Elder, Matt; Jackson, Steve; LIBLIT, Ben (Oktober 2008). Code -Sandwiches (PDF) (Technischer Bericht). Universität von Wisconsin-Madison. 1647.
  10. ^ Jay Fields; Shane Harvie; Martin Fowler; Kent Beck (2009). Refactoring: Ruby Edition. Pearson Ausbildung. S. 274–279. ISBN 978-0-321-60350-0.
  11. ^ Kräuter 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 erforderlich, dass jede Funktion genau einen Ausgang hat, was bedeutet, dass eine Rückkehrerklärung. Eine solche Anforderung ist in Sprachen veraltet, die Ausnahmen und Zerstörer unterstützen, bei denen Funktionen in der Regel zahlreiche implizite Ausgänge aufweisen.
  12. ^ Watt & Findlay 2004, S. 215–221.
  13. ^ Bertrand Meyer (2009). Berührung der Klasse: Lernen, gut mit Objekten und Verträgen zu programmieren. Springer Science & Business Media. p. 189. ISBN 978-3-540-92144-8.
  14. ^ "Single-Entry, Single-Exit, sollte es in objektorientierten Sprachen immer noch anwendbar sein?". Peter Ritchies MVP -Blog. Archiviert vom Original am 2012-11-14. Abgerufen 2014-07-15.
  15. ^ Watt & Findlay 2004, S. 221–222.
  16. ^ Kenneth C. Louden; Kenneth A. Lambert (2011). Programmiersprachen: Prinzipien und Praktiken (3. Aufl.). Cengage -Lernen. p. 423. ISBN 978-1-111-52941-3.
  17. ^ Arvind Kumar Bansal (2013). Einführung in Programmiersprachen. CRC Press. p. 135. ISBN 978-1-4665-6514-2.
  18. ^ Weimer, W. & Necula, G.C. (2008). "Außergewöhnliche Situationen und Programmzuverlässigkeit" (PDF). ACM -Transaktionen zu Programmiersprachen und Systemen. 30 (2). 8:27. doi:10.1145/1330017.1330019. S2CID 3136431. Archiviert von das Original (PDF) Am 2015-09-23.
  19. ^ Rohit Chandra (2001). Parallele Programmierung in OpenMP. Morgan Kaufmann. p. 45. ISBN 978-1-55860-671-5.

Quellen

Externe Links

  • Bpstruct - Ein Werkzeug zur Strukturierung von gleichzeitigen Systemen (Programme, Prozessmodelle)
  • J. Darlinton;M. Ghanem;H. W. to (1993), "Strukturierte parallele Programmierung", In Programmiermodellen für massiv parallele Computer.IEEE Computer Society Press.1993: 160–169, Citeseerx 10.1.1.37.4610