Ich las Code Complete und in dem Kapitel über Layout und Stil sagte er voraus, dass Code-Editoren eine Art Rich-Text-Formatierung verwenden würden. Das heißt, anstatt wie folgt auszusehen

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

es könnte ungefähr so ​​aussehen:

Verfahren ResolveCollisions

Führt eine nachträgliche Kollisionsauflösung durch räumlichen Partitionierungsalgorithmus durch

Parameter

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

Lokale Variablen

• Collider : Sprite
• Collidee : Sprite
• Collision : SpriteCollision

    DoStuff();

Ich habe Syntaxfarben und Hervorhebungen und sogar Klammern gesehen, aber nichts, was im tatsächlichen Code so aussah. Ich fragte mich, ob es so etwas überhaupt jemals gab, oder ob vielleicht entschieden wurde, dass es nicht genug Nutzen hatte oder dass es eine völlig schlechte Idee war.

Hat jemand von Ihnen schon so einen reich formatierten Code gesehen oder weiß er, ob die Idee jemals in Betracht gezogen und letztendlich abgelehnt wurde?

Es gibt keinen technischen Grund, den Sie nicht konnten. Wenn Texteditoren Syntaxhervorhebungen durchführen können, können sie auch andere Aspekte der Anzeige ändern, um Code hervorzuheben.

Es ist jedoch eine Sache, dass das, was gerade eingegeben wird, die Farben ändert, wenn der Editor herausfindet, was Sie eingeben. Wenn sich die Größe des Textes plötzlich ändert und Sie während des Schreibens herumspringen, wird dies wirklich unangenehm.

Bei einer "statischen" Codeanzeige kann der Quellcode jedoch leicht verschönert werden. Nehmen Sie zum Beispiel einen halbwegs anständigen Quell-> HTML-Konverter und fügen Sie den Stylesheets beliebige Schriftgrößen und -stile hinzu, und Sie erhalten reichhaltigen formatierten Code.

Einfacher Grund: Editor- / Tool-Unabhängigkeit.

Sobald Sie Ihren Code "rich" gemacht haben, wird er an den von Ihnen verwendeten Editor gebunden oder an diejenigen, die Rich-Code verstehen können. Alle anderen Editoren, die mit dem Reichtum nicht umgehen können, zeigen Kauderwelsch.

Ebenso würde Rich Code nicht gut mit Diff-Tools funktionieren. Wenn Sie zum Beispiel nur eine Formatierung geändert haben, zeigt das Diff einen Unterschied, aber es ist nicht einmal ein Unterschied, mit dem Sie am wenigsten zu tun haben.

Und was ist mit der Versionskontrolle? Wie würden Sie es anweisen, alle Änderungen in der Formatierung zu ignorieren und Dateien nur dann als geändert zu betrachten, wenn es eine "echte" Änderung gibt?

Schließlich denke ich, der springende Punkt bei Rich Code ist die Lesbarkeit - und dafür denke ich, dass bessere (und mehr) Kommentare, logische Bezeichnernamen und konsistente Einrückungen ausreichen.

Im Wesentlichen wird der Programmiertext am besten als einfacher Text behandelt - was Sie sehen, ist die Realität. ( was auch mit der pythonischen Idee von explizit besser als implizit übereinstimmt )

Vielleicht hat sich reich formatierter Code nicht durchgesetzt, weil es keine so coole Idee ist. Persönlich gefällt mir nicht, was ich in dem von Ihnen bereitgestellten Beispiel sehe. Ich benutze Syntaxfärbung und -hervorhebung, aber diese Formatierung ist zu umständlich und weicht zu sehr von der Art und Weise ab, wie ich es gewohnt bin, Code zu sehen und zu schreiben.

Warum existiert es nicht? Es gibt keine Nachfrage / Notwendigkeit dafür.

Aktuelle Editoren sind in der Lage, die Bedürfnisse von Programmierern mit Syntaxhervorhebungen und einigen anderen kleineren Stiloptionen zu befriedigen. Ist das nicht schon "Rich Text"?

Dies gibt es bereits für LaTeX im AucTeX-Modus für Emacs. Abschnittsüberschriften sind größer, Unter- und Hochschriften werden entsprechend angepasst, und Sie können sogar eine kleine Vorschau der Mathematik (und möglicherweise anderer Umgebungen wie Algorithmic) anzeigen.

Dies ist für LaTeX in Ordnung, da die Zuordnung vom Code zur Ausgabe in der Regel viel einfacher ist als in anderen Programmen. Ich glaube, das würde mir für allgemeinere Sprachen überhaupt nicht gefallen.

Eine andere Sache , Emacs tun können , ist Symbole zu ersetzen , wie ->und forallmit →und ∀jeweils in Haskell. Es gibt kaum einen Grund, warum so etwas nicht auf die Formatierung ausgedehnt werden kann, die Sie vorschlagen, außer dass es in Haskell überhaupt nicht notwendig ist.

Vor einiger Zeit habe ich diese Frage zur Code-Formatierung gestellt und gefragt, ob Programmierer ihren Code während der Eingabe formatieren möchten.

Meine Frage bezog sich nur auf den Einrückungsaspekt der Formatierung, aber einige Antworten gelten möglicherweise auch für die Code-Formatierung im Allgemeinen. Das allgemeine Gefühl in den Antworten legt nahe, dass Programmierer dagegen sind, die absolute Kontrolle über die Art und Weise zu verlieren, in der ihr Code dargestellt wird.

Meine persönliche Erfahrung war ganz anders. Obwohl ich normalerweise öffentlich verfügbare Tools verwende, muss ich manchmal XSLT in meinem eigenen, maßgeschneiderten Editor schreiben. Dieser Editor formatiert den Code während der Eingabe, indem er am linken Rand eingerückt wird, sodass ich keine Probleme mit unerwünschten Leerzeichen habe (was für XSLT von Bedeutung ist). Außerdem kann der Code in Zeilenumbrüche umgewandelt werden und die Formatierung bleibt erhalten. Ich finde das Erlebnis ganz natürlich, der Formatierungsstil wird allein vom Kontext und der Position der Zeilenvorschübe bestimmt (das Erlebnis ist besonders lohnenswert, wenn Sie berührungsempfindliche Eingabegeräte verwenden).

Wenn das XSLT nicht ausgewogen ist, zeigt die Formatierung tatsächlich, wo das Problem liegt. Es hat eine Weile gedauert, bis sich der Code während der Eingabe horizontal verschoben hat, aber das ist für mich keine Ablenkung mehr. Ich habe jedoch festgestellt, dass Formatierungsfunktionen, die sich auf den vertikalen Abstand meines XSLT auswirken, den Editor nahezu unbrauchbar machen. Daher habe ich diese deaktiviert.

Um auf Ihre Frage zurückzukommen: Ich denke, der Grund, warum die Formatierung von Rich-Code nicht häufiger vorkommt, ist, dass es lange dauert, bis sich die Wahrnehmungen in der Programmierwelt ändern. Ihre Zeit wird möglicherweise mit der Zeit zusammenfallen, in der die Codebearbeitung überwiegend ohne Tastatur erfolgt.

Auch in mehr als ein paar Sprachen (Haskell, Ruby, Python, Erlang, CoffeeScript ein paar andere) ist Einrückung wichtig. Wenn Sie also die Schriftgröße ändern, kann es sehr schwierig werden, dies herauszufinden.

Meistens seine Tradition. Ich programmiere seit fast 20 Jahren professionell und ich vermute, das würde mich verrückt machen. Ich schreibe Bücher in Emacs oder VI mit docbook, also bin ich kein WYSIWIG-Fan

Knuths CWEB macht das, aber es funktioniert nur für C / C ++ und Pascal. - Du solltest es dir aber ansehen ... es ist ziemlich ordentlich. Es gibt zwei Programme: ctangleund cweavedie CWEB-Dateien in TeX bzw. C kombinieren / trennen.

Hat jemand von Ihnen schon so einen reich formatierten Code gesehen oder weiß er, ob die Idee jemals in Betracht gezogen und letztendlich abgelehnt wurde?

Sicher. Xcode unterstützt Stile jenseits der einfachen Farbgebung für unterschiedliche Syntax:

Ich habe es schon lange nicht mehr benutzt, aber ich glaube, Metrowerks CodeWarrior hat auch gestalteten Text unterstützt, und das war vor über 10 Jahren.

Sie möchten die Stile jedoch nicht übertreiben - Text, Quellcode oder Ähnliches sind möglicherweise schwerer zu lesen, wenn die Stile zu stark variieren. Insbesondere finde ich, dass das Mischen von Größen störend ist, und alles, was dazu führt, dass Spalten nicht in einer Reihe stehen, ist ärgerlich. Es gibt einen Grund, warum die meisten Programmierer immer noch monospaced Schriftarten verwenden.

Eine andere Frage ist, ob formatierter Text als Teil der Sprachsyntax selbst verwendet werden soll. Soll der Compiler beispielsweise die Tatsache verwenden, dass ein Teil des Texts auf eine bestimmte Weise formatiert ist, um festzustellen, dass es sich bei dem Text um eine Funktionsdeklaration handelt? Das mag zunächst verrückt klingen, aber Sprachen wie Python und Fortran verwenden bereits Einrückungen als Syntax. Dennoch denke ich, dass es wahrscheinlicher ist, dass der Stil weiterhin von der Syntax bestimmt wird und nicht umgekehrt. Die Verwendung von einfachem Text (einfachere Compiler, Plattformunabhängigkeit, Programmiererpräferenzen) und andere Traditionen haben zahlreiche Vorteile, die es ermöglichen, Code ohne Stile (Einrückungen, Leerzeilen, Markierungszeichen und) lesbar zu machen Editorfunktionen wie Code-Faltung und Navigationsmenüs).

Ich denke, dass eine umfangreiche Formatierung des Quellcodes nicht sehr beliebt ist, da sie für die Eingabe von Informationen gedacht ist, bei denen Struktur und Bedeutung weitaus wichtiger sind (und auch einfacher zu tippen sind). Schrift, spezielle Symbole und Leerzeichen sorgen für unnötiges visuelles Rauschen. Dies kann jedoch für generierte Dokumentationen angemessen sein.

Es gibt nie endende Flammenkriege um dasselbe Thema in der Schriftsatzwelt zwischen denen, die WYSIWYG-Editoren (wie MS Word) und Systeme wie TeX (LaTeX) bevorzugen.

Im Allgemeinen gibt es keine endgültige Antwort. Alles hängt von Tools, Anwendungsfällen und persönlichen Vorlieben ab.

Tools wie Doxygen oder JavaDoc führen bereits die Formatierung von Rich-Text-Code durch. Sie fügen auch Code-Hypertext zum Durchsuchen hinzu. Sie müssen keine speziellen Tags für die Grundformatierung einfügen.

Dies ist jedoch kein WYSIWYG.

Ich habe Angst zu sagen, dass es das gibt.

In der Vergangenheit habe ich an einigen Centura gearbeitet (auch bekannt als Gupta oder SQL / Windows - ein alter " 4GL " Codes " -Code) gearbeitet. Es war nicht wirklich möglich, Centura-Code in einem Standard-Editor zu bearbeiten, wie es der Editor für die extremen Formatierungsanforderungen tut.

Obwohl es vielleicht so aussieht, als wäre es eine gute Idee, eine Quelldatei so formatieren zu lassen, empfand ich die Entwicklung als recht restriktiv und schmerzhaft.

Darüber hinaus verursachte die Formatierung häufig Probleme beim Zusammenführen in der Quellcodeverwaltung.

Zusätzlich zu den anderen Antworten möchte ich darauf hinweisen, dass es neben den technischen Schwierigkeiten bei der Verwendung einer umfangreichen Formatierung auch ein Objekt persönlicher Präferenz ist.

Wenn Sie einfachen Text bearbeiten, können Sie die gewünschten Schriftarten und Farben auswählen. Diese werden automatisch festgelegt. Wenn Sie Rich-Text bearbeiten möchten, was ist, wenn Sie bestimmte Farben und Schriftarten, die manuell festgelegt wurden, nicht mögen?

Ich denke, das liegt daran, dass noch niemand das Lesen und Schreiben von Code getrennt hat. Zumindest wird es nicht zum Mainstream. Manchmal müssen Sie Code lesen, den Sie vor langer Zeit berührt haben, oder Code, der von anderen Entwicklern erstellt wurde. Sie müssen wahrscheinlich viel Zeit aufwenden, bis Sie bereit sind, ein einzelnes Byte in dieser Quelle zu ändern. Dies könnte der "Lese" -Modus sein, der alles tun kann, was zum leichteren Verständnis erforderlich ist (Schriftgröße, Neuformatierung, Unterskript, Superskript usw.). Wenn Sie bereit sind, kann der Editor in den "Schreib" -Modus wechseln und weniger restriktiv sein und die "Regel der geringsten Überraschung" befolgen.