Wie kann ein Code-Editor effektiv auf die Ebene der Code-Verschachtelung hinweisen - ohne Einrückung? [geschlossen]

Ich habe einen XML-Texteditor geschrieben , der zwei Ansichtsoptionen für denselben XML-Text bietet, einen eingerückt (virtuell), den anderen linksbündig. Die Motivation für die linksbündige Ansicht besteht darin, den Benutzern zu helfen, die Whitespace-Zeichen, die sie zum Einrücken von Klartext- oder XPath-Code verwenden, ohne Beeinträchtigung durch Einrückungen, die ein automatischer Nebeneffekt des XML-Kontexts sind, zu "sehen".

Ich möchte visuelle Hinweise (im nicht bearbeitbaren Teil des Editors) für den linksbündigen Modus geben, die dem Benutzer helfen, ohne jedoch zu aufwendig zu werden.

Ich habe versucht, nur Verbindungsleitungen zu verwenden, aber das schien zu beschäftigt zu sein. Das Beste, was ich bisher gefunden habe, ist in einem Screenshot des Editors unten dargestellt, aber ich suche nach besseren / einfacheren Alternativen (die nicht zu viel Code erfordern).

[Bearbeiten]

Ausgehend von der Heatmap-Idee (von: @jimp) erhalte ich diese und 3 Alternativen - bezeichnet mit a, b und c:

Im folgenden Abschnitt wird die akzeptierte Antwort als Vorschlag beschrieben, in dem Ideen aus einer Reihe anderer Antworten und Kommentare zusammengefasst werden. Da diese Frage jetzt Community-Wiki ist, können Sie sie gerne aktualisieren.

NestView

Der Name für diese Idee, die eine visuelle Methode zur Verbesserung der Lesbarkeit von verschachteltem Code ohne Einrückung bietet.

Umriss

Der Name für die unterschiedlich schattierten Linien in NestView

Das obige Bild zeigt das NestView, das zur Visualisierung eines XML-Snippets verwendet wird. Obwohl für diese Abbildung XML verwendet wird, könnte für diese Abbildung jede andere Codesyntax verwendet werden, die Verschachtelung verwendet.

Ein Überblick:

1. Die Konturlinien sind (wie in einer Heatmap) schattiert, um die Verschachtelungsebene anzuzeigen

2. Die Konturlinien sind abgewinkelt, um anzuzeigen, wann eine Verschachtelungsebene geöffnet oder geschlossen wird.

3. Eine Konturlinie verbindet den Anfang einer Verschachtelungsebene mit dem entsprechenden Ende.

4. Die kombinierte Breite der Konturlinien gibt zusätzlich zur Heatmap einen visuellen Eindruck der Verschachtelungsebene.

5. Die Breite von NestView kann manuell geändert werden, sollte sich jedoch nicht ändern, wenn sich der Code ändert. Konturlinien können entweder komprimiert oder abgeschnitten werden, um dies zu erreichen.

6. Leerzeilen werden manchmal als Code verwendet, um Text in besser verdauliche Teile aufzuteilen. Solche Zeilen können im NestView ein spezielles Verhalten auslösen. Beispielsweise könnte die Heatmap zurückgesetzt werden oder eine Konturlinie mit Hintergrundfarbe verwendet werden oder beides.

7. Eine oder mehrere Konturlinien, die dem aktuell ausgewählten Code zugeordnet sind, können hervorgehoben werden. Die Konturlinie, die der ausgewählten Codeebene zugeordnet ist, wird am stärksten hervorgehoben. Es können jedoch auch andere Konturlinien aufleuchten, um die enthaltene verschachtelte Gruppe hervorzuheben

8. Mit dem Klicken / Doppelklicken auf eine Konturlinie können unterschiedliche Verhaltensweisen (z. B. Falzen von Code oder Auswahl von Code) verknüpft werden.

9. Unterschiedliche Teile einer Konturlinie (Vorder-, Mittel- oder Hinterkante) können unterschiedliche dynamische Verhalten aufweisen.

10. QuickInfos können angezeigt werden, wenn Sie den Mauszeiger über eine Konturlinie bewegen

11. Das NestView wird kontinuierlich aktualisiert, während der Code bearbeitet wird. Wenn die Verschachtelung nicht ausbalanciert ist, können Annahmen getroffen werden, wo die Verschachtelungsebene enden soll, aber die zugehörigen temporären Konturlinien müssen in gewisser Weise als Warnung hervorgehoben werden.

12. Drag & Drop-Verhalten von Konturlinien kann unterstützt werden. Das Verhalten kann je nach dem Teil der Konturlinie variieren, der gezogen wird.

13. Funktionen, die häufig am linken Rand zu finden sind, wie Zeilennummerierung und farbige Hervorhebung bei Fehlern und Statusänderungen, können das NestView überlagern.

Zusätzliche Funktionalität

Der Vorschlag befasst sich mit einer Reihe zusätzlicher Probleme - viele liegen außerhalb des Rahmens der ursprünglichen Frage, sind jedoch ein nützlicher Nebeneffekt.

Visuelles Verknüpfen von Anfang und Ende einer verschachtelten Region

Die Konturlinien verbinden den Anfang und das Ende jeder verschachtelten Ebene

Hervorheben des Kontexts der aktuell ausgewählten Zeile

Wenn Code ausgewählt ist, kann die zugehörige Verschachtelungsebene in der NestView hervorgehoben werden

Unterscheidung zwischen Coderegionen auf derselben Verschachtelungsebene

Im Fall von XML können für verschiedene Namespaces unterschiedliche Farbtöne verwendet werden. Programmiersprachen (wie c #) unterstützen benannte Regionen, die auf ähnliche Weise verwendet werden könnten.

Unterteilen von Bereichen innerhalb eines Sammelbereichs in verschiedene visuelle Blöcke

Zusätzliche Zeilen werden häufig in den Code eingefügt, um die Lesbarkeit zu verbessern. Solche leeren Zeilen könnten verwendet werden, um den Sättigungsgrad der NestView-Konturlinien zurückzusetzen.

Mehrspaltige Codeansicht

Code ohne Einrückung macht die Verwendung einer mehrspaltigen Ansicht effektiver, da ein Zeilenumbruch oder horizontales Scrollen weniger wahrscheinlich ist. In dieser Ansicht fließt der Code, sobald er das Ende einer Spalte erreicht hat, in die nächste:

Verwendung, die über die bloße Bereitstellung einer visuellen Hilfe hinausgeht

Wie in der Übersicht vorgeschlagen, könnte NestView eine Reihe von Bearbeitungs- und Auswahlfunktionen bieten , die im Großen und Ganzen den Erwartungen eines TreeView-Steuerelements entsprechen. Der Hauptunterschied besteht darin, dass ein typischer TreeView-Knoten aus zwei Teilen besteht: einem Expander und dem Knotensymbol. Eine NestView-Konturlinie kann bis zu drei Teile haben: einen Öffner (abfallend), einen Verbinder (vertikal) und einen Schließer (abfallend).

Einrückung

Das NestView wird zusammen mit nicht eingerückten Code-Ergänzungen angezeigt, wird jedoch wahrscheinlich die herkömmliche eingerückte Code-Ansicht nicht ersetzen.

Es ist wahrscheinlich, dass alle Lösungen, die NestView verwenden, eine Methode bieten, mit der nahtlos zwischen eingerückten und nicht eingerückten Codeansichten gewechselt werden kann, ohne dass sich dies auf den Codetext selbst auswirkt - einschließlich Leerzeichen. Eine Technik für die eingerückte Ansicht wäre "Virtuelle Formatierung", bei der ein dynamischer linker Rand anstelle von Tabulator- oder Leerzeichen verwendet wird. Dieselben Verschachtelungsebenendaten, die zum dynamischen Rendern von NestView verwendet werden, können auch für die herkömmlichere Ansicht mit eingerückten Rändern verwendet werden.

Drucken

Einrückungen sind wichtig für die Lesbarkeit des gedruckten Codes. In diesem Fall bedeutet das Fehlen von Tabulator- / Leerzeichen und einem dynamischen linken Rand, dass der Text am rechten Rand umgebrochen werden kann und trotzdem die Integrität der eingerückten Ansicht erhalten bleibt. Zeilennummern können als visuelle Markierungen verwendet werden, die angeben, wo der Code in Worte gefasst ist, und auch die genaue Position der Einrückung:

Screen Real-Estate: Flat Vs Indented

Beantwortung der Frage, ob der NestView wertvolle Bildschirmfläche verbraucht:

Konturlinien funktionieren gut mit einer Breite, die der Zeichenbreite des Code-Editors entspricht. Eine NestView-Breite von 12 Zeichen kann daher 12 Verschachtelungsebenen aufnehmen, bevor Konturlinien abgeschnitten / komprimiert werden.

Wenn eine eingerückte Ansicht 3 Zeichenbreiten für jede Verschachtelungsebene verwendet, wird Platz gespart, bis die Verschachtelung 4 Verschachtelungsebenen erreicht. Nach dieser Verschachtelungsebene hat die flache Ansicht einen platzsparenden Vorteil, der mit jeder Verschachtelungsebene zunimmt.

Hinweis: Für Code wird häufig ein Einzug von mindestens 4 Zeichen empfohlen, XML kann jedoch häufig mit weniger Zeichen auskommen. Durch die virtuelle Formatierung kann außerdem weniger Einrückung verwendet werden, da kein Risiko für Ausrichtungsprobleme besteht

Ein Vergleich der beiden Ansichten ist nachfolgend dargestellt:

Auf der Grundlage der obigen Ausführungen ist es wahrscheinlich gerechtfertigt, den Schluss zu ziehen, dass die Auswahl des Ansichtsstils auf anderen Faktoren als Bildschirmimmobilien basiert. Die einzige Ausnahme ist, wenn der Platz auf dem Bildschirm knapp ist, z. B. auf einem Netbook / Tablet oder wenn mehrere Codefenster geöffnet sind. In diesen Fällen scheint das in der Größe veränderbare NestView ein klarer Gewinner zu sein.

Anwendungsfälle

Beispiele für Beispiele aus der Praxis, bei denen NestView eine nützliche Option sein kann:

1. Wo Bildschirmimmobilien an erster Stelle stehen

   ein. Auf Geräten wie Tablets, Notizblöcken und Smartphones

   b. Beim Anzeigen von Code auf Websites

   c. Wenn mehrere Codefenster gleichzeitig auf dem Desktop angezeigt werden sollen

2. Wo konsistente Leerzeichen Einrückung von Text im Code eine Priorität ist

3. Zum Überprüfen von tief verschachteltem Code. Zum Beispiel, wenn Untersprachen (z. B. Linq in C # oder XPath in XSLT) einen hohen Verschachtelungsgrad verursachen können.

Barrierefreiheit

Anpassungs- und Farboptionen müssen bereitgestellt werden, um Sehbehinderten zu helfen und um den Umgebungsbedingungen und persönlichen Vorlieben gerecht zu werden:

Kompatibilität des bearbeiteten Codes mit anderen Systemen

Eine Lösung mit einer NestView-Option sollte idealerweise in der Lage sein, führende Tabulator- und Leerzeichen (die nur eine Formatierungsrolle haben) aus importiertem Code zu entfernen. Sobald der Code entfernt wurde, konnte er ohne Änderungen sowohl in der linksbündigen als auch in der eingerückten Ansicht sauber gerendert werden. Für viele Benutzer, die sich auf Systeme wie Mergen und Diff-Tools verlassen, die keine Whitespace-Kenntnisse haben, ist dies ein großes Problem (wenn nicht sogar ein kompletter Show-Stopper).

Andere Arbeiten:

Visualisierung überlappender Markups

Die veröffentlichte Studie von Wendell Piez aus dem Jahr 2004 befasst sich mit der Visualisierung von überlappenden Markups , insbesondere LMNL . Dies beinhaltet SVG-Grafiken mit signifikanten Ähnlichkeiten zum NestView-Vorschlag. Sie werden hier als solche anerkannt.

Die visuellen Unterschiede sind in den Bildern (unten) deutlich zu erkennen. Der wichtigste funktionale Unterschied besteht darin, dass NestView nur für gut verschachteltes XML oder Code gedacht ist, während Wendell Piez Grafiken so gestaltet sind, dass sie überlappende Verschachtelungen darstellen.

Die obigen Grafiken wurden - mit freundlicher Genehmigung - von http://www.piez.org reproduziert

Quellen:

1. Auf dem Weg zu Hermenutic Markup
2. Halbschritte in Richtung LMNL

Ich habe versucht, meine eigene Frage hier zu beantworten, aber dies bezieht die Heatmap-Idee von @jimp und auch die Idee von @Andrea mit ein, dass es XML-gerechter wird:

Hoffentlich helfen die Farben in der Heatmap zusammen mit den eckigen Linien dabei, das Auge zwischen den Start- und End-Tags zu ziehen. Das Entfernen der horizontalen Linientrenner verbessert den Durchfluss von Anfang bis Ende. Wenn der Benutzer ein Element auswählt, kann der entsprechende Teil in der Heatmap auf irgendeine Weise hervorgehoben werden - möglicherweise mit einem leuchtenden Rand (wie gezeigt).

Bearbeiten hat beschlossen , mit diesem zu gehen, es wird wahrscheinlich Benutzeroptionen für die Farben sein. Ein 'produktionsbereiter' Screenshot:

Und zum Vergleich ... die alternative eingerückte Ansicht:

Edit Now, für den stärker verschachtelten Fall - Testen meiner Zeichenfähigkeiten ...

Eine Idee könnte sein, zu versuchen, dem Text 3D hinzuzufügen. Erhöhen / verringern Sie die Schriftgröße basierend auf der Stufe, auf der sie sich befindet.

Zum Beispiel dieser Code:

Würde so aussehen:

Das ist möglicherweise ärgerlich, da die feste Ausrichtung der Textgröße über verschiedene Ebenen hinweg verloren geht. Eine andere Idee; ändere die Sättigung jedes Levels:

Wie gut hält das für etwas wirklich Tiefes aus? Nicht sicher...

Ich mag Ihre Idee zur Rinnenvisualisierung sehr. Es ist einfach, Dinge zu gruppieren. Vielleicht sieht es in Kombination mit einer dieser Ideen sogar noch besser oder viel schlechter aus. ;)

Vor einiger Zeit habe ich eine Heatmap erstellt, die den Umfang von C zeigt. Vielleicht macht es Spaß, sie für ein Brainstorming anzusehen:

Linksbündig:

Optimieren Sie einfach Ihre ursprüngliche Idee und wechseln Sie von Quadraten zu Kapseln. Ich denke, diese Versionen (einschließlich Ihrer Originalversion) sind einfacher zu lesen, da sie weniger komplex sind als die, bei der das Verschachteln durch Verschachteln der Anzeigeelemente angezeigt wird. Ich denke, Baumelemente vermitteln die Informationen auf einfachere und intuitivere Weise.

Ich denke, die linke Seite eignet sich hervorragend, um Einrückungen direkt anzuzeigen, während die rechte Seite eine verschachtelte Beziehung besser vermitteln kann.

Meine Idee:

Die Verschachtelung ähnelt eher einer Verschachtelung. Die horizontale Breite jeder Schicht muss nicht so breit sein.

Ich liebe die Idee. Mein Vorschlag, um die "beschäftigt" zu halten, wäre, Farbverläufe anstelle von Quadraten zu verwenden. Es würde die Anzahl der Leitungen verringern. Vielleicht verschiedene Farben für extreme Eindrücke.

Ich würde sagen, dass alles, was Sie haben, großartig ist, auch wenn es für meinen Geschmack etwas blockig ist.

Meine Kommentare: Ich habe ständig mit der Art und Weise zu kämpfen, wie die Visual Studio-IDE Einrückungen ausführt. Ich würde gerne so etwas oder eine Variation verwenden.

Stellen Sie sich diesen Link ohne die Zeilen vor und fügen Sie ihn in Ihre aktuelle XML / Ihren aktuellen Code ein.

Da Sie sagten, dass die Visualisierung im nicht bearbeitbaren (linken?) Rand vorhanden sein muss, glaube ich, dass die Visualisierung nicht vermischt werden kann oder sich hinter dem Code befindet.

Vielleicht eine Heatmap in der linken Spalte, deren hellere Farben eine tiefere Einrückung anzeigen? Stellen Sie den Rand auf eine feste Größe ein, mit einer Visualisierung wie der, die Sie haben (von links nach rechts gehen, wie es der Einzug tun würde), die dynamisch den gesamten angegebenen Raum gemäß dem maximalen Einzug verwendet, der durch die DOM-Tiefe bestimmt wird.

Wenn Sie bereit wären, in den Editorbereich zu verzweigen, würde ich etwas sehr Ähnliches vorschlagen, aber als Hintergrund des Dokuments. Der schattierte Bereich würde sich dort befinden, wo Leerzeichen wären, wenn die Einrückung aktiviert wäre. In diesem Fall würde ich eine feste, helle Farbe verwenden, die sich von der Hervorhebung des Texts abhebt.

jGRASP verwendet dazu einen visuellen Marker am Rand:

Es erkennt sogar, wenn Sie eine Schleife verwenden, und verwendet einen anderen Linientyp, um diese innere Schleife darzustellen.

Ich dachte nur, ich würde darauf hinweisen, wie es ein existierender Editor macht.

Keine schlechte Idee, aber auf den linken Rand verweisen zu müssen, um meine Blöcke deutlich zu sehen, könnte etwas nervig werden. Dabei geht es nicht einmal um Bildschirmimmobilien oder darum, wie die Dinge aussehen könnten, wenn die Struktur sehr tief wird.

Da die Motivation darin besteht, den Benutzern zu helfen, die Leerzeichen, die sie zum Einrücken verwenden, zu "sehen", können Sie ihnen einfach die Leerzeichen anzeigen.

Ich spreche nicht von speziellen visuellen Zeichen wie Absatzmarken, sondern nur von Hervorhebungen. Leerzeichen in Gelb, Tabulatoren in Grün (oder was auch immer)

Für das Rand- / Verschachtelungsproblem können Sie einfach den Rand für jeden Block verschieben. Es gibt nichts, was besagt, dass der Rand eine gerade Linie sein muss.

Ich bin sicher, das ist keine neue Idee.

Etwas wie das:

Warum nicht Klammern öffnen und schließen?

1. Einrückung bedeutet Einschluss: (und) bedeuten genau das für Programmierer.
2. (und) sind jeweils ein einzelnes Zeichen: Der linke Balken bleibt sehr dünn.
3. Leere Elemente lassen sich leicht erkennen: Verwenden Sie () in derselben Zeile.
4. Der Inhalt eines Elements benötigt keinen visuellen Hinweis: Ein Leerzeichen ist viel besser.
5. Die Cursorposition auf der rechten Seite kann mit dem enthaltenen Block auf der linken Seite abgeglichen werden: Fügen Sie den Zeichen in der Spalte mit (und) dynamisch eine Farbe hinzu.
6. Mit <und> können Sie das XML-isch machen, was aus der Ferne besser aussieht.

Vim kann schon etwas Ähnliches, wenn auch nicht ganz so hübsch.

In Vim gibt es verschiedene Möglichkeiten, Code zu falten. Einer von ihnen basiert auf Syntaxfaltregeln. In diesem Fall kann der Code mithilfe einer verschachtelten Gliederungsstruktur gefaltet werden, und die "FoldColumn" kann verwendet werden, um eine grafische (tatsächlich "zeichenbasierte" Darstellung des "Foldlevel" mit "|" und "-" Zeichen zu erhalten. .

Die Fold-Spalte kann unabhängig von der Fold-Methode die Verschachtelungsdarstellung liefern, aber die syntaxbasierte Methode ist wahrscheinlich diejenige, die für das, was Sie wollen, geeignet ist. Ich bin mir nicht sicher, ob es vorgefertigte syntaxbasierte Faltregeln für XML gibt.

Ich denke, Sie sind mit Option B und C auf dem richtigen Weg: Fügen Sie sowohl die Breite als auch die Heatmap-Farbe hinzu. Ich mag Option B im Moment mehr als C, weil es weniger aufdringlich ist (entweder breit und verdünnt, oder schmal und intensiv, anstatt des sehr schweren Blocks in der Mitte von C). Ein Nachteil ist, dass man das mit dieser Option tun muss Erstellen Sie das gesamte Diagramm neu, wenn Sie irgendwo eine Ebene einfügen. Ich denke man könnte die Blöcke viel kleiner machen, 1 oder 2 px wären wahrscheinlich genug. Es muss nicht viel sein, es muss nur unterscheidbar sein. Insbesondere, wenn erwartet wird, dass die Benutzer den Editor häufig verwenden, ist es einfacher, mit unauffälligen, subtileren Effekten zu arbeiten, da sie nicht so sehr ablenken.

Wenn Sie einen Editor verwenden, ist es wichtig, den aktuellen Bereich hervorzuheben: Wenn Sie eine Zeile im Editor auswählen, müssen Sie genau sehen, welche Elemente darin enthalten sind und wo sie aufhören. Sie können den Baum sogar hervorheben (von welchen Elementen ist er ein Kind). Ich denke, das ist ein separates Thema, das angesprochen und überlegt werden muss und mehr Einfluss darauf haben wird, wie die Benutzer ihre Erfahrungen mit dem Editor bewerten.

Eine Sache, die ich nicht erwähnt habe, ist, was Sie mit dem Farbton zusätzlich zu dem Sättigungseffekt tun können, auf den Sie sich eingestellt zu haben scheinen. Mein Vorschlag ist, die Farbe des Nestes zu ändern, in dem der Zeiger liegt. Dies würde es dem Benutzer erleichtern, zu unterscheiden, welche Linien Teil des Nestes sind, und welche Geschwister sich auf dem Weg dorthin befinden.

Achten Sie beim Implementieren von farbtonbasiertem Material auf Farbenblindheit und wählen Sie entweder Farben aus, die allgemein unterscheidbar sind, oder bieten Sie ein paar Optionen zur Auswahl an.

Eine Möglichkeit, die bisher in Verbindung mit den anderen Vorschlägen verwendet werden könnte, wäre die Verwendung eines Tooltips am linken Rand, der den Pfad zur Linie in XPath-Notation anzeigt. Browser-Tools zum Überprüfen von Elementen (z. B. Firebug, das in Chrome integrierte Tool) führen häufig ähnliche Aktionen aus, jedoch in einer Statusleiste.

Möglicherweise könnten Sie eine komprimierte Ansicht für die Heatmap (aus dem ursprünglichen Beitrag) mit nur einer Farbspalte und den Tiefenzahlen haben. Dies würde es ihnen ermöglichen, zu wissen, wie tief sie sind, und ihnen mehr Platz auf dem Bildschirm für die XML-Datei geben. Scheint mir ein Gewinn zu sein.

Ich mache mir Sorgen, ob es genügend Farbunterschiede gibt, um die Dinge tief zu verschachteln.