• Eine lesbare Notation für Algorithmen ohne syntaktische Strenge, die Elemente aus populären ProgrammierSprachen benutzt, um das Wesen eines Algorithmus für Menschen verständlich darzulegen. (Hauptbedeutung)
• Nebenbedeutung: Programmcode für eine VirtuelleMaschine, den PseudoCodeInterpreter. Meist abgekürzt als P-Code. Beispiele: UcsdPascal, JavaVirtualMachine, CommonLanguageRuntime, MmixProzessor, SprachePerl)

Idealerweise (IMHO) sollte gut geschriebener Code einer Programmiersprache bereits selbst aussehen wie Pseudocode. Von den Sprachen, die ich kenne, kommt Python diesem Ideal am nächsten. --FalkBrügmann

Wenn aussagekräftige Bezeichner verwendet werden, funktioniert das auch mit C++ oder Java. Allerdings ist es dort eine Frage der Programmierdisziplin (Python kenne ich nur ganz oberflächlich).

Andererseits fehlt Neulingen oft einfach das "Auge" dafür:

while (keys.hasMoreElements()) { hash.get(keys.nextElement()).doSomething(); } "Solange noch Keys vorhanden sind, hole aus dem Hash und mach etwas." "Aja, genau..."

Eins-zu-eins in Python übersetzt wäre das beispielsweise:

for key in hash: hash[ key ].doSomething()

Wenn ich Pseudocode schreibe, sieht es ziemlich genauso aus. --FalkBrügmann

Ich finde nicht, dass obiges sehr nach Pseudocode aussieht und denke bei Pseudocode mehr an Dinge wie:

WIEDERHOLE für alle Kunden WENN letzte Kundenbestellung älter als 5 Jahre DANN Kunden löschen WENN_ENDE WIEDERHOLE_ENDE

also etwas, das für einen Nichtprogrammierer auch gerade noch verständlich ist, sich aber nahezu 1:1 in Code umsetzen lässt.

In diesem konkreten Fall, wo es also auch für einen Nichtprogrammierer gerade noch verständlich sein soll, und es sich aber auch nahezu 1:1 in Code umsetzen lassen können soll, könnte - sofern man noch keine Programmiersprache bereits im Auge hat - der Pseudocode auch einfacher

Lösche die Kunden mit länger als 5 Jahre zurückliegender letzter Bestellung.

lauten, weil so - im Gegensatz zur obigen Formulierung - gerechterweise der Einsatz einer prozeduralen Programmiersprache nicht bereits präjudiziert ist. Interessanterweise ist (wie ich gerade sehe) aus dem Pseudocode ein normalsprachlicher Satz geworden.

Ich finde, folgendes ist doch sehr lesbar:

keys do:[:eachKey | (hash at:eachKey) doSomething ]

oder gleich:

hash do:[:eachValue | eachValue doSomething ]

Das Obiges 'sehr lesbar' sein soll, kann ich nicht nachvollziehen. Schon die Bedeutung der zusätzlichen Zeichen ':' und '|' hat Erklärungsbedarf. Oder war bei ':[:' einfach nur der Drucker kaputt?

Bei PseudoCode sollte die Betonung auf 'Pseudo' liegen, und nicht auf 'Code'.

Idealerweise kann man mit PseudoCode auch jemandem die Funktionsweise eines Programmteils verdeutlichen, der keine Programmierkentnisse hat.

Ich glaube man müsste da die PseudoCode-Anwendungen "Ausbildung" und "Programmierung" unterscheiden. Während es in der Ausbildung sinnvoll ist, für Laien verständlich zu sein, ist es in der Programmierung vielleicht vorteilhafter, einen PseudoCode zu verwenden, der zwar noch für jeden Programmierer verständlich ist, aber schon möglichst nahe an der mitgedachten Implementierung liegt.

Frage

Ich hatte mal die Idee, Projekte zuerst in PseudoCode zu beginnen und dann Schritt für Schritt durch echten Code zu erweitern. Der PseudoCode wird dabei als Kommentare übernommen bzw. muß weiter mitgepflegt werden. Über einen kleinen Parser kann man dann am Schluss den PseudoCode extrahieren, evtl. nach HTML oder RFT umwandeln und hat damit seine Algorithmen dokumentiert.

Gibt es so etwas in der Praxis ? Hat jemand damit Erfahrungen gemacht ? -- JoachimStolberg?

Nennt sich UML :-)

Die Antwort hatte ich befürchtet. Ich hätte gleich reinschreiben sollen, dass ich keine UML-Diskussion anzetteln will :-) -- JoachimStolberg?

Also jetzt eine ernsthafte Antwort. Ich habe neulich nebenbei ein kleines Projekt für Microchips in Assembler gemacht. Dort bin ich genauso, wie Du es vorschlägst vorgeganen. Zuerst habe ich mir die StateMachine?s skizziert, dann für jeden Zustand die Zustandsprozedur im Pseudocode niedergeschrieben, und dann nach und nach den Pseudocode in Assembler übersetzt. Der PseudoCode blieb als Kommentar drin.

Die Erfahrungen sind ganz gut, allerdings muss ich anmerken, dass ich den Pseudocode nur deswegen wertvoll fand, weil Assembler nicht so gut kommuniziert, was für einen Zweck der Code hat. (Zumindest ich erkenne es nicht sofort, weil ich im Assembler nur selten programmiere). Es hat mir geholfen den Code schneller zu debuggen, bzw. schneller die Ursache der Bugs zu erkennen. Als ich die Bugs behoben habe, habe ich immer den Pseudocode angepasst.

Wäre die Programmiersprache eine abstraktere (z.B. C) würde ich aber keinen Pseudocode verwenden. Der Abstand zwischen der Abstraktionsebene des Pseudocode und der verwendeten Programmiersprache muss groß genug sein, um einen semi-formalen Pseudocode zu rechtfertigen. Ist der Abstand zu klein, ist es besser vermutlich direkt den Code "selbsterklärend" zu schreiben, oder, wenn der Code noch nicht vorhanden ist, eine informelle ToDo-Bemerkung zu verwenden. -- GregorRayman

Bei Assembler denke ich, ist die Sache klar, da geht es kaum ohne. Wenn es aber gelingt, über eine generierte Dokumentation den Umfang auf 1/4 oder weniger zu reduzieren, so dass mit dem Printout von einer Seite eine Funktion von mehreren Seiten beschrieben werden kann, dann ist doch eine gewisse "Abstraktionsebene des Pseudocodes" erreicht ? -- JoachimStolberg?

Eine Funktion die mehrere Seiten umfasst ist zu lang. Wenn die Programmiersprache so lange Funktionen erzwingt, ist Pseudocode (bzw. viele Kommentare) vermutlich eine richtige Vorgehensweise. Es ist schwieriger den Code zu lesen als ihn zu schreiben. Wenn die Quelltexte nicht selbst lesbar sein können, sind Pseudocode bzw. Kommentare wertvoll. Da der Pseudocode genau das gleiche beschreiben soll, was der echte Code macht, hben wir hier eine Redundanz, und bei jeder Anpassung müssen die Entwickler eine Sache zweimal "implementieren". Einmal im Pseudocode, einmal im richtigem Code. Dies ist eine potenzielle Fehlerquelle. Deswegen werden Kommentare als CodeSmell betrachtet - Parfüm, der wenn in Maßen verwendet den Code verbessert, zu viel davon, und der Kopf beginnt weh zu tun. -- GregorRayman

Zu: "Deswegen werden Kommentare als CodeSmell betrachtet"; Das betrifft Kommentare, die das beschreiben, was man eh im Code sieht. Ich bin ein Fan von Kommentaren, die das beschreiben, was man nicht sieht (etwa eine verworfene Alternative). -- SDö

Kommentare, die das beschreiben, was man im Code sieht sind einfach Gestank. Kommentare, die das beschreiben, was im Code steht, aber man es nicht sieht, sind eben das Parfüm, von dem ich sprach. Sie duften angenehm und verdecken so den Geruch des unlesbaren Code. Wenn man viel Parfüm braucht, ist es ein Indikator dafür, dass zu viel des Code undurchsichtig und unlesbar ist. Kommentare, von denen Du sprichts, die nicht das beschreiben, was im Code steht, zähle ich zu einer ganz anderen Kategorie - zur eingebetten Dokumentation des Code und dessen Geschichte. Wenn richtig gepflegt, sind sie wertvoll und verbreiten den Duft von Vertrautheit und Geborgenheit :-) -- GregorRayman