Sollte man Pseudocode vor der eigentlichen Codierung verwenden?

Pseudocode hilft uns, sprachunabhängig Aufgaben zu verstehen. Ist es eine bewährte Methode oder ein empfohlener Ansatz, Pseudocode als Teil des Entwicklungslebenszyklus zu erstellen? Zum Beispiel:

• Identifizieren und teilen Sie die Codierungsaufgaben
• Pseudocode schreiben
• Lass es genehmigen [von PL oder TL]
• Starten Sie die Codierung basierend auf Pseudocode

Ist das ein vorgeschlagener Ansatz? Wird es in der Industrie praktiziert?

Das Schreiben von Pseudocode vor dem Codieren ist sicherlich besser als das reine Codieren ohne Planung, aber es ist keineswegs eine bewährte Methode. Testgetriebene Entwicklung ist eine Verbesserung.

Noch besser ist es, die Problemdomäne zu analysieren und Lösungen mit Techniken wie User Stories, Use Cases, CRC-Karten und Diagrammen zu entwerfen, die von Methoden wie Cleanroom, RUP, Lean, Kanban, Agile usw. unterstützt werden.

Das gründliche Verständnis der Art des Problems und der Komponenten, die Sie zur Implementierung der Lösung verwenden, ist das Prinzip der Best Practices.

Ich benutze Kommentare als eine Art Pseudocode auf sehr hoher Ebene, indem ich die Kommentare erst schreibe, bevor ich den Code schreibe. Ich finde, dass das Durchdenken des gesamten Problems, auch auf hoher Ebene, meinen Code erheblich verbessert.

Nein, zuerst nicht pseudocodieren

Das ist zu viel Aufwand. Sie schreiben die Logik ohne die Vorteile. Ich würde stattdessen Folgendes vorschlagen:

1. Prototyp in der Sprache, mit der Sie ausgeliefert werden (AKA Schreiben Sie eine zum Wegwerfen )
2. Architekturdiagramme mit Codeausschnitten zum Testen von Annahmen / Schlüsseldesigns
3. Test Driven Development, bei dem Sie zuerst Ihre Schnittstellen- / Codestruktur schreiben, gefolgt von Tests, gefolgt von der Implementierung des Codes.

Im Gegensatz zum Pseudocode bewegen Sie sich mit allen drei Schritten direkt auf Ihre Lösung zu. Persönlich tendiere ich dazu, Techniken 1 oder 2 anzuwenden, abhängig von der Teamgröße. Für kleinere Teams (z. B. 5 Personen oder weniger) funktioniert das Prototyping sehr gut. Bei größeren Teams mit mehreren Entwicklergruppen, die parallel arbeiten, hat sich gezeigt, dass die Dokumentation, die mit Technik 2 zu Beginn erstellt wurde, gut funktioniert, da Sie frühzeitig auf diese Probleme eingehen und die Komponentengrenzen besser definieren können. Ich bin mir sicher, dass TDD auch sehr gut funktionieren würde, aber ich muss noch in einem Team arbeiten, das sich diesem Prozess verschrieben hat.

Meiner Meinung nach hat Pseudocode nur zwei gültige Zwecke:

(1) Für Programmierstudenten, die die Konzepte von Modularität und Algorithmen erlernen müssen, aber noch keine Programmiersprache beherrschen.

(2) Kommunikation, wie etwas für eine nicht-technische Person funktioniert, oder nur aus Gründen der Zweckmäßigkeit in einem White-Board-Meeting.

Ist Pseudocode ein vorgeschlagener Ansatz? Für Programmieranfänger sage ich ja. Es hilft dem neuen Programmierer zu lernen, wie ein Problem in Code übersetzt wird, ohne sich um die genaue Syntax der Sprache zu kümmern. Dies prägt den Denkprozess und kann dazu beitragen, nützliche Gewohnheiten zu verinnerlichen (und ich nehme an, auch schlechte Gewohnheiten). Deshalb wird es in Schulen so oft verwendet.

Wird es in der Industrie praktiziert? Nach meiner Erfahrung nein. Niemand hat die Zeit, das Projekt zwischen der Dokumentation (Anforderungen, Spezifikationen, Storyboards, Anwendungsfälle oder was auch immer sie sonst verwenden) und dem tatsächlichen Code zu schruppen. Im Allgemeinen wird davon ausgegangen, dass das Problem bereits vor dem Start der Codierung gründlich durchdacht wurde. Zu diesem Zeitpunkt ist das Codieren des Projekts wichtiger als das Hinzufügen einer weiteren Ebene der Entwurfsvorbereitung.

Ich würde definitiv Pseudocode empfehlen. Es hilft Ihnen zu klären, was Sie tun werden, und Elemente zu identifizieren, die Sie möglicherweise vergessen haben oder bei denen es zu Problemen kommen kann. Es ist viel einfacher / schneller, Ihren Code zu reparieren, wenn er sich noch in der Planungsphase befindet, anstatt zu warten, bis Sie bereits einen großen Teil davon codiert haben.

Pseudocode kann nützlich sein, wenn Sie mit der Sprache nicht vertraut sind oder wenn Sie mentale Kontexte ändern müssen. In den seltenen Fällen schreibe ich Pseudocode auf Papier. Manchmal hilft es, nur die Hände von der Tastatur zu nehmen und auf Papier zu kritzeln, um eine mentale Blockade zu umgehen.

Aber als formalisierter Teil des Entwicklungsprozesses? Auf keinen Fall. Es ist ein sporadisch hilfreiches Tool für Einzelpersonen. Es gibt bessere Möglichkeiten, "zu wissen, was Sie schreiben, bevor Sie es schreiben":

1. Definieren Sie den Vertrag (vor / nach / unveränderliche Bedingungen) der Methode, bevor Sie beginnen
2. TDD
3. 1 und 2 kombiniert (schriftliche Tests zur Vertragserfüllung)

Ich würde auch vorschlagen, dass das Erhalten von Genehmigungen, bevor Sie mit dem Schreiben von Code beginnen, wahrscheinlich viel mehr Aufwand verursacht, als es wert ist. Entwurfsprüfungen (Vorimplementierung) können nützlich sein, müssen jedoch höher sein als einzelne Algorithmen.

Ich werde mit den vorherigen Antworten nicht einverstanden sein und nein sagen, aber mit einer Einschränkung: Sie können den Pseudocode nur loswerden, wenn Sie sich fieberhaft der Umgestaltung Ihres Codes widmen, um Probleme zu lösen, die auftauchen. Pseudocode ist im Wesentlichen eine Möglichkeit, Ihren Code zu definieren, bevor Sie Ihren Code definieren. Es ist unter vielen Umständen eine unnötige Abstraktion, und da Ihr Code niemals beim ersten Mal perfekt sein wird (und wahrscheinlich nicht bis zur Fertigstellung dem Design des Pseudocodes folgt), scheint es mir fremd zu sein.

Wenn Sie COBOL oder C schreiben, kann Pseudocode hilfreich sein, da das Schreiben des eigentlichen Codes viel länger dauert. Wenn Sie Ihren Algorithmus / Ihre Anforderungen anhand des Pseudocodes überprüfen können, können Sie Zeit sparen.

In moderneren Sprachen ist Pseudocode weniger sinnvoll. Besser wäre es, Methoden-Stubs zu schreiben und die Logik der obersten Ebene auszufüllen und so detailliert wie nötig zu sein, um den Algorithmus und die Anforderungen zu verifizieren. Dies alles in tatsächlichem Code. Sie können diesen Code dann dem Teamleiter zur Genehmigung vorlegen und Ihren tatsächlichen Code bereits starten lassen.

Die einzigen Male, die ich in den letzten 10 Jahren Pseudocode verwendet habe, sind Interviews, wenn wir an einem Whiteboard arbeiten und die jeweilige Sprache keine Rolle spielt.

Es ist sicherlich hilfreich, um einen Prozess / Algorithmus in loser Form durchzusprechen, ohne sich mit der Syntax abzufinden. Schreiben Sie beispielsweise eine C ++ - Klasse mit C # -Eigenschaften, um den Punkt zu veranschaulichen.

Es hat seinen Platz, sollte aber nur dort verwendet werden, wo es gebraucht wird (es ist Arbeit, die Sie wegwerfen werden) und ist sicherlich nicht Teil eines formalen Prozesses, es sei denn, Sie haben ISO-Standards, die darauf bestehen.

Für mich und die Leute, mit denen ich in den letzten Jahren zusammengearbeitet habe, hat sich der Pseudocode zu einem nicht ganz perfekten echten Code entwickelt. Wenn Sie nicht mit vielen Sprachen gleichzeitig arbeiten, scheinen die meisten Menschen im allgemeinen Muster ihrer Hauptsprache zu denken. Ich habe eine Weile in .net-Shops gearbeitet, daher sehen die meisten Whiteboard-Kritzeleien im Büro eher wie vb oder c # aus, wobei ein Teil der Zeichensetzung fehlt.

Die Übung ist immer noch wertvoll, wenn Sie über Optionen und Ähnliches diskutieren, aber das sprachunabhängige Teil verschwindet, wenn Sie mehr Zeit mit ein paar Sprachen verbringen.

Pseudocode wird zunehmend mit Tools wie UML grafisch geschrieben. Probieren Sie zum Beispiel yUML aus .

ein Online-Tool zum Erstellen und Veröffentlichen einfacher UML-Diagramme. Es macht es Ihnen wirklich leicht:

• Betten Sie UML-Diagramme in Blogs, E-Mails und Wikis ein.
• Veröffentlichen Sie UML-Diagramme in Foren und Blog-Kommentaren.
• Verwenden Sie direkt in Ihrem webbasierten Bug-Tracking-Tool.
• Kopieren Sie UML-Diagramme und fügen Sie sie in MS Word-Dokumente und Powerpoint-Präsentationen ein ...

... yUML spart Ihnen Zeit. Es wurde für diejenigen entwickelt, die kleine UML-Diagramme und Skizzen erstellen möchten.

Ohne yUML muss zum Erstellen eines UML-Diagramms möglicherweise ein UML-Tool geladen, ein Diagramm erstellt, ein Name vergeben, mit dem Layout herumgespielt, in eine Bitmap exportiert und dann irgendwo online hochgeladen werden. yUML bringt Sie nicht dazu, irgendetwas davon zu tun ...

Gute Arbeit. Sie haben eine gute Diskussion angefangen. Meiner Meinung nach habe ich Pseudocodes geschrieben, als ich das Programmieren lernte, um die verschiedenen Schleifen und Algorithmen zu verstehen. Das war vor mehr als eineinhalb Jahrzehnten. Damals waren selbst Programmiersprachen nicht sehr mächtig ... und ereignisgesteuertes Programmieren war Zukunft. Jetzt mit 4GLs und 5GLs denken wir eher in der Sprache selbst als in einfachem Englisch. Wenn wir an ein Problem denken, denken wir in Objekten und Operationen. Und bis es ein komplexes Algo ist, macht das Schreiben von Pseudocodes (oder PSEU-DO-Codes, nur ein Scherz) keinen Sinn. Stellen Sie die Lösung besser grafisch dar.

Hängt von der verwendeten Sprache und Ihrer Vertrautheit damit ab.

Viele moderne Sprachen wie Python oder Java sind dem Pseudocode bereits so nahe, dass es verschwenderisch ist, zuerst einen Ad-hoc-Pseudocode zu schreiben. Tun Sie es besser sofort mit dem Tracer-Bullet- Ansatz.

Es ist eine andere Sache, wenn Sie ein bisschen Low-Level machen, in der Nähe von Metal-Dingen sind oder sich mit der Sprache, die Sie verwenden, noch nicht auskennen. Dann kann Pseudocode durchaus nützlich sein.

Es gibt einige Umstände, unter denen Pseudocode in meiner Arbeit häufig ausbricht. In der akademischen Welt wird die Programmierung in der Regel als Werkzeug verwendet.

1. Wenn der Code zu einem tatsächlichen Verständnis dessen, was passieren wird, kontraproduktiver sein wird als Pseudocode. SAS wird zum Beispiel die Hälfte des Whiteboards für ziemlich einfache Programmieraufgaben belegen. Siehe auch C, das einige andere Poster besprochen haben.
2. Bei vielen Datenanalysen und Statistiken wird häufig am Code herumgebastelt, während die Ergebnisse generiert werden. Pseudocode ist etwas einfacher zu verwenden für "Hier liegt ein Hin- und Her-Prozess. Wenn die Diagnose nicht richtig aussieht, versuchen Sie es mit X".
3. Die Schüler lernen viele verschiedene Programmiersprachen. Ich kenne beispielsweise Personen, die ein Statistikproblem in SAS, R oder Stata analysieren. Etwas, das etwas erfordert, das der traditionellen Programmierung näher kommt, kann in R, Matlab, C, C ++, Java, Python usw. ausgeführt werden. Dies hängt wirklich davon ab, welcher Schüler das Programm ausführt und zu welchem ​​Zweck. Dennoch ist es für die Java-Leute, die Python-Leute und die Matlab-Leute nützlich, eine gemeinsame Vorstellung davon zu haben, was die anderen tun und wie der Ansatz und nicht der Code selbst funktioniert.

Dies ist keine Ja / Nein-Frage. Man sollte sich eher fragen, wann man Pseudocode benutzt. Es ist wichtig, das Problem zu verstehen, bevor Sie eine Lösung entwerfen, und eine klare Sicht auf die Lösung zu haben, bevor Sie sie implementieren. Pseudocode kann in einem der folgenden Schritte verwendet werden:

1. Bei der Definition des Problems werden häufig Anwendungsfälle aufgeschrieben, manchmal in Abfolgen von Aktionen.
2. Beim Entwerfen einer Lösung. Klassendiagramme sind nett, aber sie beschreiben nur den "statischen" Teil, dh die Daten. Für den dynamischen Teil halte ich Pseudocode für die beste verfügbare Methode, sobald Sie sich mit einer Schleife und nicht trivialen Daten befassen müssen. Zu den grafischen Alternativen gehören Zustandsautomaten (gut für komplexe Steuerungsabläufe mit wenigen Daten) und Datenflussdiagramme (gut für einfache Abläufe mit komplexen Daten).
3. Bei der Implementierung der Lösung (oder kurz zuvor). Einige Programmiersprachen sind schwer zu lesen (Denken, Assemblieren). Eine alternative Darstellung kann in diesem Fall sinnvoll sein. Wenn Sie mit den Sprachen nicht vertraut sind, lohnt es sich auch.

Es wird auch Pseudo-Code verwendet, der eigentlich der richtige Code in einer höheren Sprache ist. Dies wird normalerweise als Prototyping bezeichnet.

Neben dem Verständnis ist Pseudocode auch gut für die Kommunikation.

Wenn Sie sich fragen, ob Sie regelmäßig Pseudo-Code verwenden sollten, bin ich persönlich gegen alle Arten von starren Regeln. Dies kann leicht zu einer langweiligen Zeitverschwendung werden, wenn es um unbedeutende Probleme geht, die jeder im Team versteht. Die Verwendung von Pseudocode für Spezifikationen, die Sie während der gesamten Projektlaufzeit pflegen, kann ebenfalls kostspielig und wenig wertvoll sein.