Es gibt Fälle, in denen echter Code vorzuziehen ist, und Fälle, in denen Pseudocode vorzuziehen ist. Sie sollten sich nicht auf eine einfache Eisenregel verlassen, sondern auf die Beurteilung der Situation.

Einige Dinge, die Sie beachten sollten:

Programmiersprachen kommen und gehen In den 60er Jahren galt Fortran als eine wirklich schöne und lesbare Programmiersprache, die viel einfacher zu lesen war als Assembly. Wenn Sie jedoch einen Artikel mit Fortran-Codebeispielen anstelle von Peudocode geschrieben hätten, wäre es für uns jetzt schwieriger, ihn zu lesen. Im Moment sieht Python für uns ziemlich gut aus, aber wird es auch in Zukunft so gut aussehen? Wenn ich Ihnen ein Stück Python-Code mit dem folgenden Code übergeben habe:

  a = 3/2  

Was ist der Wert von ? ein ? Ist es 1 oder 1,5? Weil Python 2 und 3 die Ganzzahldivision unterschiedlich behandeln. Jetzt habe ich mehr oder weniger native Programmierung in Python 3 durchgeführt, also musste ich tatsächlich nachsehen, welche der Divisionsoperationen in Python 2 und 3 unterschiedlich sind und welche nicht. Nur um Ihnen zu zeigen, dass die Verwendung von echtem Code in einem Papier die Haltbarkeit Ihres Papiers verkürzen kann.

Mit Pseudocode können Sie Dinge abstrahieren. Im Pseudocode können Sie einfach Folgendes angeben:

  WÄHREND das Stoppkriterium DO nicht erreicht hat (stuff)  

Und später in Ihrem Artikel können Sie über verschiedene mögliche Stoppkriterien für Ihren Algorithmus streiten. Sie könnten dies auch mit tatsächlichem Python-Code tun, aber das Ergebnis wäre im Grunde, dass Sie Ihren Python-Code verdrehen, um das zu tun, was Pseudocode von Natur aus tut.

Sie können in Pseudocode Verwenden Sie einfach die verschiedenen Algorithmus-Satzoptionen für LaTeX.

Sie können die mathematische Notation im Pseudocode verwenden. Die Verwendung der mathematischen Notation ist viel universeller, als sich auf alle Ihre Leser zu verlassen Python-Set-Operationen verstehen. Betrachten Sie:

  a = set ([1, 2, 3]) b = set ([1, 2]) c = 1, wenn b.issubset (a) else 0  

versus

  A ← {1, 2, 3} B ← {1, 2} C = 1, wenn B ⊆ A 0 sonst  

Jemand, der mit Python nicht vertraut ist Das erste Beispiel wird sich fragen: Ist [1, 2, 3] eine ... vielleicht eine Liste? Nun, die Liste [1, 2, 3] ist nicht die gleiche wie die Liste [1, 2], daher enthalten die Menge A und die Menge B unterschiedliche Elemente, sodass B keine Teilmenge von A sein kann.

Algorithmen vs. Implementierungen Angenommen, Sie schreiben 2019 einen interessanten Algorithmus in Python 3 unter Verwendung einiger hochmoderner Bibliotheken. Im Jahr 2025 habe ich einen alternativen Algorithmus für das gleiche Problem in Go entwickelt und möchte die Leistung vergleichen, um zu beweisen, dass Ihre besser ist. Um einen fairen Vergleich zu erhalten, muss ich meinen Algorithmus in Go oder Ihren in Python implementieren. Angenommen, bis dahin verwendet niemand mehr Python für Hochleistungssachen, weil Go es besser macht. (Es kann sein, ich weiß nicht.) Jetzt muss ich die sieben Jahre alten Bibliotheken durchsuchen, die Sie verwendet haben, um herauszufinden, welche Funktionen Sie verwendet haben und welche Go-Funktionen ihnen entsprechen. Das ist sehr schwer. Es ist also sehr wahrscheinlich, dass die Go-Implementierung, die ich von Ihrem Algorithmus mache, nicht so gut sein wird. Und große Überraschung! Mein Algorithmus ist besser als Ihr Benchmark!

Wenn Sie stattdessen eine implementierungsunabhängige Beschreibung Ihres Algorithmus verwendet haben, könnte es für Ihre Veröffentlichung besser werden.

Also Die beiden großen Nachteile der Verwendung von echtem Code sind: Es begrenzt die Haltbarkeit Ihrer Publikation und Sie erreichen ein kleineres Publikum.

Wann sollten Sie also echten Code verwenden?

• Wenn das Thema Ihres Papiers nicht der Algorithmus ist, sondern die Implementierung oder die Programmiersprache. Vielleicht möchten Sie zeigen, dass Python eine wirklich gute Sprache ist, um Problem X zu lösen, da Sie mit den Bibliotheken Y und Z eine einfache und effiziente Implementierung erhalten.

• Es wird dringend empfohlen, auch Ihren echten Code als Anhang oder noch besser in einem Repository zu veröffentlichen, in dem Benutzer Ihren Code herunterladen und Verbesserungen vorschlagen können. Ein nicht trivialer Algorithmus ist wahrscheinlich zu groß, um ihn von Hand zu kopieren oder sogar aus einem Papier zu kopieren. Sobald Sie sich mit einem neuen Deep-Learning-Algorithmus befassen, sehen Sie sich wahrscheinlich mehrere Dateien oder sogar verschachtelte Pakete an.

In meiner Forschung schreibe ich häufig Algorithmen, die Aussagen enthalten können wie:

• Finden Sie einen dominanten Unterraum einer bestimmten Einsiedlermatrix A mit relativer Genauigkeit Ɛ .
• Finden Sie eine nichtnegative Lösung dieses Gleichungs- / Ungleichungssystems.
• Sortieren Sie diese Eigenwerte im Modul von groß nach klein, verwerfen Sie kleine und mischen Sie die Eigenvektoren neu entsprechend.

Diese Anweisungen sind für jeden, der numerische lineare Algebra ausführt, ganz einfach und klar, unabhängig von seiner bevorzugten Programmiersprache. Ich sehe keinen Grund, eine bestimmte Programmiersprache in der Zeitung zu verwenden, und riskiere, meine Leserschaft zu begrenzen. Ich glaube, dass die natürliche Sprache schneller zu lesen und zu verstehen ist. Insbesondere kann ich klar darüber sprechen, was der Zweck jedes Schritts ist, und nicht darüber, wie er erreicht werden kann. Es gibt oft mehr als einen Weg, z. "Löse ein lineares System", und die Verwendung von Pseudocode ermöglicht es mir, zwischen "Löse es irgendwie" und "Löse es mit diesem speziellen Algorithmus" zu unterscheiden. Daher verwende ich Pseudocode, mit dem ich Nuancen wie diese besser ausdrücken kann.

Ich stelle immer den eigentlichen Code neben dem Papier in einem offenen Repository bereit, das die Leser klonen und untersuchen können, um ihnen die Mühe des erneuten Tippens zu ersparen den Code aus der PDF- / gedruckten Version des Papiers.

Pseudocode ist für immer; Echte Sprachen ändern sich ständig.

Wenn Sie in Python 2 Tagen einen Artikel mit einem Algorithmus in Python veröffentlicht haben, besteht eine erhebliche Wahrscheinlichkeit, dass der "ausführbare" Code, den Sie damals geschrieben haben funktioniert nicht mehr ordnungsgemäß, wenn Benutzer es unter der neuesten Version ausführen. Selbst in weniger dramatischen Fällen wird der Fortschritt neuer Bibliotheken und Algorithmen die Leser wahrscheinlich hinsichtlich Ihrer archaischen Entscheidungen verwirren. Stellen Sie sich vor, Papiere von vor 40 Jahren hätten die Sprachen des Tages verwendet. Würden Sie die Feinheiten eines Fortran- oder Pascal-Codes verstehen? Programmierer haben dann die gleichen Behauptungen zur Verständlichkeit aufgestellt, die Sie über Python aufgestellt haben.

Pseudocode ist also besser, weil es die Schlüsselideen in hundert Jahren genauso gut klar zum Ausdruck bringt.

Pseudocode drückt die Absicht des Codes besser aus als echte Sprachen.

Um Arbeitscode zu schreiben, muss ich fast immer eine Reihe von Schritten ausführen, damit das Programm funktioniert Diese Schritte, die nicht erforderlich sind, um Dinge einzurichten, zu formatieren oder was auch immer, können im Pseudocode ignoriert oder vereinfacht werden, um die wichtigen Informationen zu kommunizieren.

Außerdem muss ich in echten Sprachen Treffen Sie Entscheidungen darüber, wie Daten gespeichert werden, welcher Algorithmus zum Sortieren verwendet wird usw., die mit dem in diesem Artikel diskutierten Algorithmus verbunden sind. Indem Sie diese zufälligen Entscheidungen in Ihre Beschreibung des Algorithmus aufnehmen, führen Sie die Implementierer dazu, Entscheidungen zu treffen, die möglicherweise nicht optimal sind, entweder weil jetzt bessere Entscheidungen verfügbar sind oder weil die von Ihnen getroffenen Entscheidungen für ihre Zielumgebung ungeeignet sind.

Die Argumente, die Sie gehört haben, sind möglicherweise alle richtig. Ich war Rezensent und Autor vieler Informatikartikel und möchte diese Frage auf meine Art und Weise beantworten.

Pseudocode ist kürzer. In einer modernen Sprache wie Clojure oder Python ist der echte Code oft nicht viel länger. Selbst wenn dies der Fall ist, ist (elektronisches) Papier billig.

Der Pseudocode ist kurz und klar verständlich. Pseudocode hilft bei der Dekodierung der Idee im Vergleich zu einem ganzen Code sehr deutlich. Ich werde nicht ein paar Stunden meiner Zeit damit verbringen, Ihren Code zu verstehen. Um beispielsweise eine CSV-Datei anhand der dritten Spalte zu sortieren, haben Sie möglicherweise drei Zeilen geschrieben, die mir eigentlich egal sind. Ich muss nur verstehen, dass die Datei sortiert werden muss. Zweitens, was ist, wenn mir die Sprache, in der der Code geschrieben ist, nicht gefällt? Eine solche Überprüfung und ein solches Interesse könnten eine große Tendenz aufweisen.

Nicht jeder kann in Python codieren. Richtig, aber gut geschriebener Python-Code ist nicht schwerer zu lesen als Pseudocode. Außerdem ist Python standardisiert - jemandes persönlicher Pseudocode nicht.

Dies ist nur eine Behauptung, dass die Python-Community für alle ist. Dies gilt auch für viele andere Sprachen: Matlab-Skripte, R-Skripte, Java-Skripte; Einige Leute (z. B. ich) lieben auch UNIX-Shell-Skripte.

In CS konzentrieren wir uns auf Algorithmen - nicht auf Implementierungen. Richtig, aber auch das Anzeigen von Implementierungen nimmt diesen Fokus nicht auf.

Ich stimme dem zu. Es macht jedoch keinen Sinn, den gesamten Code zu betrachten. Lesen Sie den ersten Punkt.

Es wird eine Sprache einer anderen vorgezogen. Stimmt, aber das ist ein Recht, das ich als Autor habe, nicht wahr?

Sie sollten verstehen, dass Sie das Papier für "die Welt außer sich selbst" schreiben. Sie befinden sich also nirgends in der vorgesehenen Lesergruppe. Sie sollten etwas schreiben, das die Leser lesen, um sich nicht zu ärgern.

Es sieht amateurhaft aus. Das ist subjektiv.

In der Tat.

Urteil: Sie können jederzeit vollständigen Code in Ihrem Papier angeben (as im Anhang oder im ergänzenden Material). Sie müssen jedoch im Hauptpapier einen Algorithmus / Pseudocode angeben.

Ich mag die aktuellen drei Top-Antworten im Moment (von @ObscureOwl und @DmitrySavostyanov und @JackAidley). Ich habe jedoch das Gefühl, dass es eine Option gibt, die nicht dargestellt wird.

Sie können sowohl den Pseudocode als auch den Realcode angeben.

• Höchstwahrscheinlich die Real- Der Code ist zu lang, um in Ihrem Papier inline bereitgestellt zu werden.
• Sie würden also den Pseudocode im Papier bereitstellen.
• Dann der echte Code als Nachtrag oder Ergänzung -download oder URL.

Wenn Sie beide bereitstellen, erhalten Sie alle Vorteile von UND UND mehr.

• Sie haben alle Vorteile von Pseudocode.
• Sie haben alle Vorteile von Real-Code.
• So können Ihre Leser Ihr Papier leichter verstehen, indem sie den Pseudocode lesen und die Absicht verstehen, und wenn sie es sehr ernst meinen, können sie es dann Gehen Sie zum eigentlichen Code und verwenden Sie ihn.
• Der Code ist leichter zu verstehen, da er bereits über den Pseudocode verfügt, der die Implementierung auf niedriger Ebene erklärt.

Zuletzt bereitstellen beides sorgt für langfristiges Verständnis (Pseudocode wird nicht veraltet) UND kurz- / mittelfristig für Ihre Forschung Mehr Akzeptanz, mehr Nutzung, einfachere Reproduktion Ihrer Ergebnisse.

• Mehr kurzfristige Akzeptanz / Nutzung / Reproduktion bedeutet längerfristig mehr Auswirkungen auf andere und mehr langfristige Nutzung.

Beispiel 1

https://academia.stackexchange.com/a/140990/349 ist ein großartiges Beispiel für den Pseudocode viel besser lesbar / verständlich / absichtlich ist offensichtlich ... die Implementierung in Code würde viele Codezeilen erfordern und könnte schnell hässlich werden und zu viel Platz in einem Papier beanspruchen ... also würden Sie definitiv das Pseudo- wollen Code ... aber wenn Sie es ernst meinen und das Papier verwenden wollten ... würde mir der echte Code viele Stunden sparen ... in einigen Fällen viele Stunden / Wochen / Tage / Monate für die Neuerstellung des Pseudocodes.

Beispiel 2

Hier ist ein weiteres Beispiel. http://www.fftw.org/fftw-paper-ieee.pdf Der FFTW-Algorithmus dient zur Berechnung der Fourier-Transformation. Das Papier spricht über Algorithmen, aber die Implementierung ist auch sehr wichtig. Das Papier enthält also hauptsächlich Pseudocode und ein kleines Stück Code. Und wenn Sie die Quelle möchten, können Sie diese als zusätzlichen Download herunterladen.

Nach meiner Erfahrung als Autor und Leser ist es sehr vorzuziehen, wenn immer möglich, echten Code anstelle von Pseudocode zu verwenden. Ich habe noch nie einen Rezensenten beschweren lassen, wenn ich echten Code anstelle von Pseudocode verwendet habe.

Darüber hinaus ist echter Code nicht nur deshalb vorteilhaft, weil der Leser ihn selbst ausführen kann, sondern auch, weil der author kann es ausführen und sicherstellen, dass ihre Präsentation keine Fehler enthält.

Es ist jedoch oft immer noch schwierig, echten ausführbaren Code für die Präsentation als Algorithmus gut zu machen:

• Richtig ausführbarer Code ist nicht unbedingt verständlich. Es muss sorgfältig bereinigt, kommentiert und angeordnet werden.
• Wenn das Papier eine Analyse enthält, müssen die Codevariablen mit den Analysevariablen übereinstimmen, was bei komplexeren mathematischen Notationen ("x_hat_sub_i_prime")
• Zeilenlängen müssen oft viel kürzer sein, um in eine Papiersäule zu passen, was zusätzliche Neuformatierung und häufig Hässlichkeit verursacht.
• Es gibt oft "uninteressante", aber notwendige Teile des Codes, wie das Packen und Entpacken von Informationen aus Datenstrukturen.
• Code wird häufig mit Abhängigkeiten, Umgebung und Kontext verwickelt.
• Einige Sprachen scheinen von Natur aus "wortreich" zu sein und es ist schwierig, kompakte Einträge zu erstellen .

Angesichts all dessen denke ich, dass es für viele Autoren möglicherweise einfacher ist, einen zweifelhaften Pseudocode zusammenzuschlagen, als zu versuchen, echten Code sowohl präsentabel als auch korrekt zu machen.

Mit Pseudocode können Sie sich auf die wichtigen Teile des Algorithmus konzentrieren und den Rest zusammenfassen.

Echter Code beginnt häufig damit, einige Bibliotheken zu laden, einige Daten einzulesen und sie dann nach Bedarf zu formatieren / neu anzuordnen, ohne dass dies im Pseudocode erforderlich ist.

Ihr Algorithmus besteht möglicherweise aus mehreren separaten Schritten, von denen einige Standardschritte, gut verstanden und langweilig sind, andere die Schlüsselinnovation in Ihrem Artikel sind. Im Pseudocode sind die langweiligen Bits nur Einzeiler, die beschreiben, was passieren muss. Die saftigen Stücke sind so detailliert wie sie sein müssen. Im realen Code sind einige der Standarddetails länger als die tatsächlich wichtigen Teile.

Zusammenfassend kann der Leser im Pseudocode leicht erkennen, wo sich die wichtigen Bits in Ihrem Code befinden. Bei echtem Code ist dies der Fall viel schwieriger (nicht unmöglich, nur schwieriger).

Ich würde sagen, dies ist eher eine Konvention, da dies wirklich ziemlich feldabhängig zu sein scheint. In "kombinatorischen" diskreten Algorithmuspapieren sehe ich fast nie echten Code. Eine bemerkenswerte Ausnahme ist Don Knuths TAoCP, aber nicht jeder ist Don Knuth, oder?

In einem Bereich, in dem ich arbeite (funktionale Programmierung), ist es jedoch die Norm, echten, ausführbaren Code zu präsentieren . Ein Großteil der Forschung ist wirklich sprachabhängig, was nicht überraschend ist, aber selbst die sprachunabhängige Arbeit (z. B. rein funktionale Datenstrukturen) wird typischerweise unter Verwendung einer realen funktionalen Programmiersprache wie Standard ML oder Haskell präsentiert. Manchmal führt dies zu Verwirrung, aber da die funktionale Programmierung als Feld (obwohl sie wohl immer noch größtenteils Teil von TCS ist) ziemlich implementierungs- und programmierungsorientiert ist, möchten die meisten Leute tatsächlich echte Programme sehen.

Also IMO, das ist wirklich mehr Konvention als alles andere, und es hängt wirklich vom Feld ab. Die meisten Kombinatoriker kümmern sich um den Algorithmus selbst auf hoher Ebene sowie um seine Komplexität, aber funktionale Programmierer (oder vielleicht "Logiker") kümmern sich sehr darum, ob der Algorithmus korrekt und elegant implementiert werden kann, daher die Diskrepanz.

Es muss keine klare Unterscheidung geben.

Der wichtigste Teil des Pseudocodes ist, dass er klar lesbar sein sollte. Sie möchten sich also nicht mit Konstrukten befassen, die nicht Teil des eigentlichen Algorithmus sind, und Sie möchten sich nicht mit Syntaxkonstrukten befassen, die in einer Programmiersprache nützlich sind, aber nicht leicht zu verstehen sind, wenn Sie die Programmiersprache nicht kennen.

Ist das Pseudocode oder realer Code?

  wenn a == b: a = a% b  

Dies ist gültig Python-Code. Es ist aber auch ein lesbarer Pseudocode.

Was ist mit diesem?

  für i in Bereich (10): print (i)  

Ich würde sagen, dies ist kein (guter) Pseudocode, da das Konstrukt für nicht offensichtlich ist.

Möglicherweise können Sie den für i erhalten im Teil, aber was macht der Bereich (10) ? Selbst der -Bereich (0, 10) ist nicht wirklich klar, da es nicht offensichtlich ist, dass 10 nicht Teil des Bereichs ist.
Außerdem müssen Sie ihn beibehalten Beachten Sie, dass sich Mathematik und Informatik häufig darin unterscheiden, die Indizes mit 0 oder 1 zu beginnen.

Ich würde also sagen, dass dies viel klarer ist, aber kein gültiger Code:

  für i = 0 .. 9: print (i)  

Es gibt andere Möglichkeiten, die Absicht der for-Schleife auszudrücken, die ähnlich klar und leicht zu lesen sind. Hier können Sie versuchen, die C-Syntax für (int i = 0; i < 10; i ++) zu verwenden oder sogar den int wegzulassen.

Was zu einem guten Pseudocode gehört, ist eine übersichtliche Auflistung der Ein- und Ausgabe durch den Menschen. Also nicht

  int i = 0; i: = i + 1return i;  

sondern

  // Eingabe: // i: eine Ganzzahl, die inkrementiert werden soll // Algorithmus: o: = i + 1 // Ausgabe: // o: Die Ganzzahl, die um 1 erhöht wird  

Beachten Sie, dass ich es vermieden habe, i zum Speichern des Ergebnisses erneut zu verwenden, sondern eine Variable o verwendet habe, die nur zum Speichern der Ausgabe verwendet wird. Auf diese Weise kann auch die Anweisung return weggelassen werden, sodass der Leser nicht darüber nachdenken muss, was return tut und wohin es zurückkehrt, was für den Algorithmus nicht relevant ist.

In Im Gegensatz zu dem Beispiel am Anfang habe ich : = für die Zuweisung verwendet, um deutlicher zu machen, dass es sich um eine Zuweisungsoperation und keine mathematische Gleichung handelt.

Natürlich enthält Ihr persönlicher Stil Viele Ihrer Meinungen zu sauberem Pseudocode. Wenn Sie sich nicht sicher sind, sollten Sie sich an die verschiedenen Pseudocode-Pakete in LaTeX halten und sie ähnlich wie in den Beispielen in der Dokumentation verwenden.

Es gab eine Zeit, in der Pseudocode die klare Wahl war, da Programmiersprachen so grob waren. Die 60er und 70er Jahre, aber später - es braucht Zeit, um sicher anzunehmen, dass eine Sprache allgemein verwendet wird, und zu der Zeit fühlte es sich einfach komisch an, keinen Pseudocode zu verwenden. Ich erinnere mich an Pseudocodes mit solchen Pie-in-the-Sky-Konstrukten wie: "foreach", for-Schleifen, Schleifen überhaupt (im Gegensatz zu einer IF mit einem rückwärts gerichteten GOTO), 2D-Arrays, wenn es mit anderen ist, Funktionen mit Parametern, Variablen Namen länger als 2 Buchstaben, eine funktionierende String-Bibliothek. Im Wesentlichen war Pseudocode eine bessere, überlegene Sprache.

Einige Akademiker codieren nicht so viel und haben wahrscheinlich die gleichen Erinnerungen wie ich, in denen "diesen Pseudocode in ein FORTRAN-Programm verwandeln" keine war -triviale Zuordnung. Ich für meinen Teil erinnere mich, dass ich um 2010 Pseudocode geschrieben habe (alte Gewohnheiten) und festgestellt habe, dass 99% C ++ funktionieren und dass Pseudocode keine Sache mehr ist. Sie denken und schreiben nur in Ihrer bevorzugten Programmiersprache, mit ein paar Verknüpfungen hier und da.

Wird das Veröffentlichen von ausführbarem Code anstelle von Pseudocode gemieden?

Nicht das ich weiß, aber dies hängt wahrscheinlich von der spezifischen Subkultur des jeweiligen Feldes ab.

In der Informatik ist es vorzuziehen, Algorithmen unter Verwendung von Pseudocode anstelle von echtem Code zu beschreiben?

Es war (siehe Owens Antwort) und manchmal kann immer noch sein (siehe Überlegungen unten).

Wenn ja, warum?

[...]

Also, was sind die Argumente für Pseudo Code?

Wie viele der anderen Antworten bereits besagen: Abgesehen von naivem ausführbarem Code soll Pseudocode leicht und verstanden werden, ohne den Leser mit Unwichtigkeit zu belästigen (für den vorgestellten Aspekt) Details. Und erreicht diese Ziele normalerweise.

Wie Sie selbst sagen, hat ausführbarer Code auch seine Vorteile. Lassen Sie mich das Problem umgehen, indem Sie behaupten, dass

mit etwas Aufwand Sie beide

nutzen können (und ohne tatsächlich beide bereitzustellen, Pseudocode und separate ausführbarer Code, wie syn1kk vorschlägt.)

Idealer Code in Papieren (und, wenn möglich, anderswo) ist Pseudo -Pseudo-Code: Code, der alle positiven Eigenschaften von Pseudocode aufweist, aber zufällig ausgeführt werden kann (und tatsächlich das tut, was es schien).

Ich bin der festen Überzeugung, dass alle ausreichend gut geschrieben ausgeführt werden können Code ist nicht von Pseudocode zu unterscheiden. : Wenn jemand feststellen kann, dass bestimmter (tatsächlich ausführbarer) Code kein Pseudocode ist, weil er nicht so lesbar und leicht verständlich ist wie Pseudocode, ist dieser ausführbare Code nicht gut strukturiert genug, und sollte überarbeitet werden.

Wie erhalte ich Pseudo-Pseudo-Code?

Wie erhält man ausführbaren Code, der so einfach zu lesen ist wie Pseudo-Code?

Es sind verschiedene Aspekte zu berücksichtigen, und die Erfüllung aller Aspekte ist möglicherweise nicht immer einfach oder machbar oder manchmal sogar nicht möglich. (Dies kann ein triftiger Grund sein, tatsächlichen nicht ausführbaren Pseudocode anstelle von ausführbarem Pseudo-Pseudocode zu verwenden.)

Wählen Sie die richtige Sprache

Welche Sprache am besten geeignet ist, hängt von mehreren ab Dinge:

• Die Problemdomäne
• Ihr Lösungsansatz
• Ihr Publikum
• Die Möglichkeiten, die die Sprache für (Re) bietet Strukturieren Ihres Codes

Beachten Sie, dass für einige Kombinationen davon möglicherweise keine Programmiersprache (noch oder manchmal sogar jemals) vorhanden ist, die dies zulässt Sie schreiben ausreichend gut geschriebenen Code. Aus offensichtlichen praktischen Gründen müssen Sie auch Ihre Beherrschung der jeweiligen Sprache berücksichtigen (wie gut Sie sie anwenden können).

Machen Sie Ihren Code extrem sauber: Refactor, Refactor, Refactor

Wenn Implementierungsdetails vorhanden sind, die die Kernidee des von Ihnen beschriebenen Algorithmus verschleiern, extrahieren Sie diese (z. B. nach Konstanten, Variablen, Methoden oder Funktionen), damit Sie ihr "Wie" (ihre Implementierung) durch ersetzen können ihr "Was" (der Name des neu extrahierten Code-Dings). Wählen Sie gegebenenfalls, ob die extrahierte Implementierung oder Zuordnung in den In-Paper-Code-Auszügen nicht angezeigt werden soll. Seien Sie äußerst vorsichtig bei der Benennung der extrahierten Dinge, damit ihr Zweck (nicht unbedingt ihre Implementierung) aus ihrem Namen und ihrer Anrufsignatur äußerst klar und offensichtlich wird.

Wenn andererseits ein Algorithmus zu verstreut ist Um verschiedene Teile des Codes leicht verständlich zu machen, müssen Sie möglicherweise stattdessen selektiv Inline-Code einfügen.

Streben Sie dabei eine einzelne Abstraktionsebene pro Codeeinheit (z. B. Funktion) oder zumindest die richtigen Abstraktionsebenen an, um den Algorithmus am besten zu zeigen und zu erklären. Wenden Sie das etwas verwandte Prinzip der Einzelverantwortung jedoch nur mit Vorsicht an: Eine Überanwendung (oder eine zu enge Interpretation der "Einzelverantwortung") kann Ihren Algorithmus zerstreuen und dadurch verschleiern. Beachten Sie, dass sich in dieser Hinsicht die richtige Balance für Code zur Darstellung in einem Papier höchstwahrscheinlich von der richtigen Balance für Code in einem (zu) zu wartenden Softwareprodukt unterscheidet.

Bei ausreichender Optimierung Compiler oder Interpreter, keines dieser Refactorings sollte die Leistung zu stark beeinträchtigen. Wenn der Schwerpunkt jedoch auf der Präsentation eines Algorithmus liegt, anstatt ihn in einem Produktionssystem zu implementieren, sollte dies ohnehin nicht allzu wichtig sein.

Machen Sie Ihren Code für die Interpretation offensichtlich

Die korrekte Interpretation Ihres Pseudo-Pseudo-Codes sollte nicht davon abhängen, dass Sie die von Ihnen gewählte Programmiersprache oder deren Version, Variante oder Dialekt kennen. Seien Sie daher vorsichtig, welche Sprachfunktionen Sie verwenden.

Jede Sprachfunktion, die vielen Programmiersprachen gemeinsam ist (dem Publikum bekannt) und die in der ausgewählten Sprache eine ähnliche Syntax wie viele andere Programmiersprachen hat, könnte dies auch tun Sie können auch ein Merkmal eines Pseudocode-Dialekts sein und können daher im Pseudo-Pseudocode verwendet werden, es sei denn, die ausgewählte Programmiersprache hat eine ungewöhnliche und nicht offensichtliche Semantik. Selbst ein nicht so verbreitetes oder sprachspezifisches Merkmal oder ein Merkmal mit einer nicht so verbreiteten Syntax kann problemlos verwendet werden, wenn seine Semantik aus seiner Syntax und seinen Schlüsselwörtern und ihrer Beziehung zur natürlichen Sprache hinreichend offensichtlich ist.

Nicht offensichtliche Sprachmerkmale werden am besten weggelassen, können jedoch in Kombination mit Erklärungen in Codekommentaren oder in der Prosa des Papiers verwendet werden. (Genau wie es für nicht offensichtliche Merkmale eines ausgewählten Pseudocode-Dialekts gelten würde.)

Gleiches gilt für sprachspezifische Redewendungen: Vermeiden oder erklären Sie sie, wenn Sie erwarten müssen, dass sie für Ihr Publikum nicht offensichtlich sind.

Alternative: Pseudocode ausführbar machen

In den beiden obigen Abschnitten wird davon ausgegangen, dass Sie mit der Ausführung von ausführbarem Code beginnen. Natürlich können Sie auch von Pseudocode ausgehen und ihn so ändern, dass er tatsächlich in einer geeigneten Programmiersprache ausgeführt werden kann (und hoffentlich das tut, was er zu tun scheint). Beachten Sie jedoch, dass Sie auf diese Weise möglicherweise einen nicht idiomatischen Code für die Zielsprache erhalten, der möglicherweise nicht Ihren Wünschen entspricht. Natürlich kann Refactoring das normalerweise beheben.

Erklären Sie Ihren Code

Genau wie Sie bestimmte Aspekte Ihres Codes (in Prosa, Codekommentaren oder Beschriftungen) erklären müssten, wenn dies der Fall wäre In Pseudocode dargestellt, müssen Sie dies tun, wenn es in Pseudo-Pseudocode geschrieben ist.

Die Vorteile von Pseudo-Pseudocode

• So lesbar und verständlich wie Pseudocode
• Wenn die verwendete Sprache (inkl. Version, Variante oder Dialekt, falls zutreffend) angegeben ist:
  • ist sie ausführbar und verwendbar
  • kann sowohl manuell als auch automatisiert getestet werden Tests
  • es ist profilierbar

Einige dieser Vorteile kommen Ihnen als Autor zugute, da Sie beispielsweise sicherstellen können, dass (r) Der vorgestellte Algorithmus ist tatsächlich korrekt. Andere kommen Ihrem Publikum zugute, das möglicherweise Ihren Algorithmus bewerten möchte.

Ob diese Vorteile die erhebliche Arbeit wert sind, die erforderlich ist, um Pseudo-Pseudo-Code im Vergleich zu nur Pseudo-Code zu erzielen, oder andererseits nicht ausreichend gut geschrieben, ausführbar Code, liegt an Ihnen zu entscheiden.

Oh, und vergessen wir nicht den moralischen Vorteil: Ob "es amateurhaft aussieht" oder nicht, Sie können sicher sein, dass dies aufgrund all der Fähigkeiten nicht der Fall ist und harte Arbeit, die es erfordert.

Für eine Zeit in den späten sechziger Jahren forderte CACM, dass Algorithmen in Artikeln in Algol geschrieben werden sollten. Sie ließen die Anforderung fallen, als sich herausstellte, dass Benutzer Algorithmen einreichten, die in anderen Sprachen entwickelt und nicht in Algol getestet wurden (weil an ihren Standorten zufällig kein Algol-Compiler installiert war). Eine Folge dieses Verhaltens war, dass fast keiner der Algorithmen Die veröffentlichten Algorithmen waren kompilierbar, und viele enthielten wesentliche Fehler, die durch das Missverständnis der Autoren der Algol-Semantik verursacht wurden.

Ich denke, die CACM-Redakteure waren sich der Compilersituation bewusst, als sie die Anforderungen stellten, hofften jedoch, dass es eine klare gibt Standard würde zu eindeutigem Pseudocode führen.

Dieses Beispiel zeigt jedenfalls: * Selbst mit einem großen Standarddokument, das ihn beschreibt, ist Pseudocode schwer zu schreiben. * Die Qualitätskontrolle ist mit ausführbarem Code einfacher.

Ich sage dies, ohne jemanden zu respektieren, aber viele Akademiker sind keine begeisterten Programmierer - sie genießen es nicht, zu programmieren oder sich um Details zu kümmern. Das Programmieren ist nicht das, wofür sie sich angemeldet haben, oder es steht nicht im Mittelpunkt ihrer Arbeit. Sie sehen Code möglicherweise eher als "notwendiges Übel" als als Beitrag oder schätzen dessen Design. Der Code wird als unwichtig und niedrig empfunden. Das ist natürlich alles subjektiv: Ich bin vielleicht in der extremen Minderheit, aber ich persönlich finde Java-Code leichter zu verstehen als UML-Diagramme.

Meiner Ansicht nach dreht sich die gesamte Diskussion um Syntax. Es gibt einen Grund, warum Sie Python-Code kopieren und einfügen können und niemand ein Augenlid schlägt (Hinweis: Es ist selbst Amateuren weithin bekannt), während dies bei Sprachen mit einer steileren Lernkurve und mehr Nuancen nicht möglich ist. Es kommt einfach so vor, dass Menschen, die Code sehen, den sie nicht mögen (oder wahrscheinlich nicht verstehen können, möglicherweise teilweise aufgrund von Unkenntnis der Syntax), möglicherweise einen großen Teil des Beitrags verpassen.

Pseudocode ist von Natur aus für prozedurale Algorithmen konzipiert, die einfache IMO-Konstrukte erfordern. Es kann manchmal viel ausdrucksvoller sein, ausführbaren Code zu schreiben, je nachdem, was Sie demonstrieren. Dies bedeutet auch, dass Sie keine eigene Syntax erfinden müssen, da die meisten Pseudocode- "Standards" nur grundlegende imperative Konstrukte haben.