Warum wird beim Programmieren ein Ablaufdiagramm nicht empfohlen?

Flussdiagramme sind nicht schlecht. Sie bieten eine Abstraktion von prozedurbasierten Programmen.

Der Grund, warum Flussdiagramme in letzter Zeit weniger populär sind, ist ein anderer: Sie sind nicht gut genug, um objektorientierte Programme zu abstrahieren. UML- und Entity-Relationship-Diagramme ersetzten Flussdiagramme. Funktionen in OOP können jedoch weiterhin mithilfe von Flussdiagrammen dargestellt werden.

Ein weiterer Grund, warum Flussdiagramme weniger populär wurden, ist, dass mehr Möglichkeiten zur Darstellung von Algorithmen populär wurden. Strukturierte Textbeschreibungen von Algorithmen sind jetzt so gut wie Flussdiagramme, um Prozeduren darzustellen, und sparen Platz und Aufwand beim Zeichnen. Außerdem enthalten viele Bücher und Artikel nur Codeausschnitte in einer populären Sprache, anstatt Flussdiagramme zu geben.

Flussdiagramme werden weiterhin zur Darstellung von Prozessen, Auftragssequenzen, Entscheidungsbäumen usw. verwendet.

Im Gegenteil, Flowcharting ist eine gute Praxis.
Flussdiagrammsysteme können effektiv verwendet werden, um Folgendes zu dokumentieren:
1. funktionale Anforderungen oder Use-Case-Analyse.
2. wie diese funktionalen Anforderungen umgesetzt werden.
3. Flusskontrolle und Datenfluss auf verschiedenen Ebenen der Zersetzung, die effektiv genutzt werden können, um ein robustes und ansprechendes OO- oder Funktionsdesign zu erhalten.
Prozessabläufe haben einige Beispiele.

Im Laufe der Zeit werden Sie feststellen, dass es mühsam ist, selbst ein etwas komplexes Problem als Flussdiagramm zu zeichnen. Wir verwenden andere Modellierungstechniken wie UML, die fortgeschrittener sind und Optionen zur Beschreibung des Problems und der Lösung auf mehreren Abstraktionsebenen bieten. Es müssen nicht alle angegeben werden. Ziel ist es, das Problem zu verstehen und die Lösung zu finden und sicherzustellen Die Lösung funktioniert. Es gibt keine feste Regel dafür. Alles, was hilft, ob Diagramme, praktische Beispiele und / oder Prototypenteile der Lösung verwendet werden, um dieses Ziel zu erreichen.

Für einen streng prozeduralen Code ist es nicht unbedingt eine schlechte Praxis, aber es kann zu ziemlich schrecklichem Code führen, wenn Sie beim Erstellen des Flussdiagramms nicht klar denken. In der Verteidigung kann jedoch fast jede Art von Planungswerkzeug missbraucht werden und zu einem schlechten Ergebnis führen. Das alte Garbage-In / Garbage-Out-Syndrom. Flussdiagramme können auch sehr schwer zu ändern sein, insbesondere wenn Sie Ihren Programmfluss ändern müssen.

Ich habe mich vor vielen Jahren von Flussdiagrammen verabschiedet, als ich mit Warnier / Orr-Diagrammen bekannt wurde. Ich fand, dass sie eine viel schönere Art sind, Logik zu entwickeln, die niemals eine ‘goto’-Anweisung erfordert.

Ein Wirrwarr eines Designs ist normalerweise ein Indikator dafür, dass Sie entweder ein sehr schwerwiegendes Problem haben, es nicht sehr gut verstehen oder das falsche Werkzeug für das Design verwenden. Die Verwendung von Flussdiagrammen für sehr komplexe Entwürfe kann problematisch sein, da ein Fehler möglicherweise nicht nur auf Sie zuschlägt.

Am Ende ist ein klarer Verstand Ihre beste Verteidigung.

Eine weitere Standardfrage zum Quora-Typ. Der Fragesteller macht implizit eine lächerliche Annahme, während er eine Frage stellt. Etwas in der folgenden Form: “Warum ist C ++ die schlechteste Sprache aller Zeiten?” ist schlechte Praxis?

Ich werde eine Quelle für Ihre Behauptung liefern, vielleicht lesen Sie das hier. Der Autor hier http://wiki.c2.com/?TipsForReadi… sagt, Flussdiagramme seien für das Code-Design schrecklich. Ich benutze sie regelmäßig, um mein Denken über den Kontrollfluss eines Programms zu organisieren. Viele Leute hier sagen, dass sie sie nützlich finden.

Das Erstellen eines Flussdiagramms ist in der Programmierung so gut wie nie eine “schlechte Praxis”. Es ist vielleicht nicht entscheidend für den Erfolg eines Projekts, aber es hilft fast immer, wenn Sie nur Ihre Gedanken organisieren, aber ich kann mir keinen Fall vorstellen, in dem es zum Scheitern eines Projekts beitragen würde oder jemals eine “schlechte Praxis” sein. Wenn Sie sich nicht die Zeit nehmen, um ein Flussdiagramm zu erstellen, werden Sie gezwungen, langsamer zu fahren und zu verhindern, dass Sie ein Design entwickeln und implementieren, das Sie wirklich nicht gut durchdacht haben.

Es geht darum, mit / zu tun, was Ihnen hilft, sich besser, schneller, einfacher usw. zu entwickeln. Wenn Ihnen die Verwendung eines Flussdiagramms hilft, dann verwenden Sie es. Probleme treten hauptsächlich dann auf, wenn die Verwendung von etwas obligatorisch / institutionalisiert wird (und Sie gezwungen sind, es zu verwenden, ob es sinnvoll ist oder nicht) oder wenn jemand der Entdeckung / Verwendung anderer Ansätze im Wege steht.

Ich glaube nicht, dass Flussdiagramme schlechte Praxis sind. Erstens glaube ich, dass es beim Erlernen des Programmierens hilft. Es erfordert, dass man seine Gedanken strukturiert und lernt, wie man ein großes Problem aufnimmt und es in kleinere Gruppen aufteilt.

In der Praxis sind viele Probleme kleine Probleme, die ohne Flussdiagramme leicht gelöst werden können. Wenn ein Programmierer Kenntnisse erlangt, verwendet er Pseudocode als Ablaufdiagramm und nicht als formale Symbolik, es sei denn, die Projektspezifikation schreibt dies vor. Bei komplexen oder großen Problemen wird dieser Pseudocode fast immer benötigt, um den Arbeitsaufwand zu planen. Obwohl es sich nicht um ein formales Flussdiagramm handelt, sollte es als dasselbe wie ein Flussdiagramm angesehen werden und ist eine gute Praxis.

Weil diese Regeln durch Erziehung geschaffen werden. Sie haben keine Ahnung.

Ich Flussdiagramm, wenn auf ein Problem stecken

Flussdiagramme eignen sich hervorragend zum Verständnis neuer komplexer Systeme.

Flussdiagramme sollten nicht jede mögliche Situation enthalten. Nur die wichtigsten Punkte und halten Sie es auf 2 oder 3 Seiten max.

[1] Zeilenumbruch / Hilfslichtfunktion Seite 1

[2] Seite 2 von 2

Flussdiagramme eignen sich hervorragend für Spaghetti-Code

Fußnoten

[1] Bild auf telusplanet.net

[2] http://www.telusplanet.net/publi…

Ich kann mir zwei Fälle vorstellen:

1. Das Flussdiagramm ist nicht zu groß: Sie können die Steuerung Ihres Programms auf ~ einer Seite ausdrücken. Na wenn das der Fall ist, warum nicht lieber direkt verschlüsseln? Ihr Programm ist nicht zu kompliziert, und ein Ablaufdiagramm kann seine Funktionsweise genau darstellen, außer dass es nicht funktioniert. Schreiben Sie stattdessen sauberen Code, der auch funktioniert!
2. Das Flussdiagramm ist groß: Ihr Programm ist ziemlich komplex. Versuchen Sie, es aufzubrechen, versuchen Sie, Abstraktionen zu finden, versuchen Sie, es auf ein kleineres / einfacheres Problem zu reduzieren. Jetzt fallen die Stücke in Fall 1.

Ein besserer Weg, als in Form eines Flussdiagramms zu denken, besteht darin, in Code zu denken. Flussdiagramm ist in den meisten Fällen nicht besonders nützlich – es sei denn, Sie arbeiten mit einer Person zusammen, die keinen Code lesen kann.
Auf der anderen Seite hilft es fast immer, Fälle zu machen.

Meine $ 0.02 ..

Wenn ein Flussdiagramm für das jeweilige Problem nützlich wäre, erstellen Sie ein Flussdiagramm.

Wenn ein Flussdiagramm nicht wirklich passt, kann es kontraproduktiv sein.

Es ist eine schlechte Programmierpraxis, zu denken, dass eine Lösungsmethode zu jedem Problem passt oder in jedem Fall unbrauchbar ist. Schauen Sie sich genau an, was Sie tun müssen, und finden Sie heraus, wie Sie es am besten tun können.