it-swarm.dev

Wie kann ein Code-Editor effektiv auf die Ebene der Code-Verschachtelung hinweisen - ohne Einrückung zu verwenden?

Ich habe einen XML-Texteditor geschrieben, der zwei Ansichtsoptionen für denselben XML-Text bietet, eine (virtuell) eingerückt, die andere linksbündig. Die Motivation für die linksbündige Ansicht besteht darin, den Benutzern zu helfen, die Leerzeichen zu sehen, die sie zum Einrücken von Klartext- oder XPath-Code verwenden, ohne durch Einrückungen gestört zu werden, die ein automatisierter Nebeneffekt des XML-Kontexts sind.

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

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

code editor nesting level indication

[Bearbeiten]

Unter Berücksichtigung der Heatmap-Idee (von: @jimp) erhalte ich diese und drei Alternativen - mit a, b und c gekennzeichnet:

Initial ideas

Der folgende Abschnitt beschreibt die akzeptierte Antwort als Vorschlag und fasst Ideen aus einer Reihe anderer Antworten und Kommentare zusammen. Da es sich bei dieser Frage jetzt um ein Community-Wiki handelt, können Sie diese 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

enter image description here

Das obige Bild zeigt das NestView, mit dem ein XML-Snippet visualisiert werden kann. 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 zu vermitteln

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

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

  4. Die kombinierte Breite der Konturlinien vermittelt 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 ein spezielles Verhalten in NestView auslösen. Beispielsweise könnte die Heatmap zurückgesetzt oder eine Hintergrundfarbenkonturlinie 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. Andere Konturlinien können jedoch zusätzlich zur Hervorhebung der enthaltenen verschachtelten Gruppe aufleuchten

  8. Mit dem Klicken/Doppelklicken auf eine Konturlinie können verschiedene Verhaltensweisen (z. B. Falten von Code oder Codeauswahl) verbunden sein.

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

  10. Tooltips können bei einem Mauszeiger über einer Konturlinie angezeigt werden

  11. Das NestView wird kontinuierlich aktualisiert, wenn der Code bearbeitet wird. Wenn die Verschachtelung nicht ausgewogen ist, können Annahmen getroffen werden, wo die Verschachtelungsebene enden soll, aber die zugehörigen temporären Konturlinien müssen 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 z. B. Zeilennummerierung und Farbhervorhebung für Fehler und Statusänderung, können 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.

Visuelle Verknüpfung 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

Unterscheiden zwischen Codebereichen auf derselben Verschachtelungsebene

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

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

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

Mehrspaltige Codeansicht

Code ohne Einrückung macht die Verwendung einer mehrspaltigen Ansicht effektiver, da Word-Wrap oder horizontales Scrollen weniger wahrscheinlich erforderlich sind. In dieser Ansicht fließt der Code, sobald er den unteren Rand einer Spalte erreicht hat, in die nächste:

enter image description here

Verwendung über die bloße Bereitstellung einer visuellen Hilfe hinaus

Wie in der Übersicht vorgeschlagen, bietet NestView könnte Eine Reihe von Bearbeitungs- und Auswahlfunktionen, die weitgehend 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 3 Teile haben: einen Öffner (abfallend), einen Anschluss (vertikal) und einen schließen (abfallend).


Bei Einrückung

Die neben nicht eingerücktem Code präsentierte NestView ergänzt die herkömmliche eingerückte Codeansicht, ersetzt sie jedoch wahrscheinlich nicht.

Es ist wahrscheinlich, dass alle Lösungen, die NestView verwenden, eine Methode zum nahtlosen Umschalten zwischen eingerückten und nicht eingerückten Codeansichten bieten, ohne den Codetext selbst zu beeinflussen - 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 Daten auf Verschachtelungsebene, die zum dynamischen Rendern der NestView verwendet werden, können auch für die konventionell aussehende eingerückte Ansicht verwendet werden.

Drucken

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

enter image description here

Bildschirm Immobilien: Flat Vs eingerückt

Beantwortung der Frage, ob das NestView wertvolle Bildschirmflächen verbraucht:

Konturlinien funktionieren gut mit einer Breite, die der Zeichenbreite des Code-Editors entspricht. Eine NestView-Breite von 12 Zeichenbreiten 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 wird jedoch häufig mit weniger Zeichen verwaltet. Außerdem ermöglicht die virtuelle Formatierung die Verwendung weniger Einrückungen, da kein Risiko für Ausrichtungsprobleme besteht

Ein Vergleich der beiden Ansichten ist unten dargestellt:

enter image description here

Auf der Grundlage des oben Gesagten ist es wahrscheinlich fair zu folgern, dass die Wahl des Ansichtsstils auf anderen Faktoren als der Bildschirmfläche basiert. Die einzige Ausnahme ist, wenn der Bildschirmplatz knapp ist, beispielsweise auf einem Netbook/Tablet oder wenn mehrere Codefenster geöffnet sind. In diesen Fällen scheint das anpassbare 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 einen hohen Stellenwert haben

    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 sichtbar sein müssen

  2. Wo konsistente Leerzeicheneinrückungen von Text innerhalb von Code Priorität haben

  3. Zum Überprüfen von tief verschachteltem Code. Zum Beispiel, wenn Untersprachen (z. B. Linq in C # oder XPath in XSLT) ein hohes Maß an Verschachtelung verursachen können.

Barrierefreiheit

Größen- und Farboptionen müssen bereitgestellt werden, um Menschen mit Sehbehinderungen zu helfen und um den Umgebungsbedingungen und persönlichen Vorlieben gerecht zu werden:

enter image description here

Kompatibilität von bearbeitetem Code 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. Nach dem Entfernen kann der Code dann sowohl in der linksbündigen als auch in der eingerückten Ansicht ohne Änderung sauber gerendert werden. Für viele Benutzer, die sich auf Systeme wie Zusammenführungs- und Diff-Tools verlassen, die keine Whitespace-Kenntnisse haben, ist dies ein Hauptanliegen (wenn nicht ein vollständiger Show-Stopper).


Andere Arbeiten:

Visualisierung überlappender Markups

Die von Wendell Piez aus dem Jahr 2004 veröffentlichte Studie befasst sich mit dem Problem der Visualisierung überlappender Markups, insbesondere LMNL . Dies schließt SVG-Grafiken mit erheblichen Ähnlichkeiten zum NestView-Vorschlag ein. Daher werden sie hier anerkannt.

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

enter image description here

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

Quellen:

  1. In Richtung Hermenutic Markup
  2. Halbschritte in Richtung LMNL
235
pgfearo

Ich habe versucht, meine eigene Frage hier zu beantworten, aber dies beinhaltet die Heatmap-Idee von @jimp und auch die Idee, es mehr XML-ish zu machen von @Andrea:

enter image description here

Hoffentlich helfen die Farben in der Heatmap zusammen mit den angular -Linien, das Auge zwischen den Start- und End-Tags zu ziehen; das Entfernen der horizontalen Linientrennzeichen verbessert den 'Fluss' von Anfang bis Ende Der Benutzer wählt mit einem Element aus, dass der passende Teil in der Heatmap auf irgendeine Weise hervorgehoben werden kann - möglicherweise mit einem leuchtenden Rand (wie gezeigt).

Bearbeiten Haben Sie sich dafür entschieden, wird es wahrscheinlich Benutzeroptionen für die Farben geben müssen. Ein "produktionsbereiter" Screenshot:

enter image description here

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

enter image description here

Bearbeiten Nun zum stärker verschachtelten Fall - Testen meiner Zeichenfähigkeiten ...

enter image description here

104
pgfearo

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

Zum Beispiel dieser Code:

enter image description here

Würde so aussehen:

enter image description here

Es kann ärgerlich sein, damit zu arbeiten, da die feste Ausrichtung der Textgröße auf verschiedenen Ebenen verloren geht. Eine andere Idee; Ändern Sie die Sättigung jedes Levels:

enter image description here

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

Ihre Gutter-Visualisierungsidee gefällt mir sehr gut. Es ist einfach, Dinge zu gruppieren. Vielleicht sieht es in Kombination mit einer dieser Ideen noch besser oder viel beschissener aus. ;)


Vor einiger Zeit habe ich eine Heatmap erstellt, die den Umfang in C zeigt. Es könnte Spaß machen, nach Brainstorming zu suchen:

enter image description here

Linksbündig:

enter image description here

24
Dave Gallagher

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

capsules

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

21
Jeremy Giberson

Meine Idee:

Das Verschachteln sieht eher wie Verschachteln aus. Die horizontale Breite jeder Schicht muss nicht so breit sein.

9
broc7

Ich liebe die Idee. Mein Vorschlag, das "Beschäftigt" niedrig zu halten, wäre, Farbverläufe anstelle von Quadraten zu verwenden. Es würde die Linien reduzieren. Vielleicht verschiedene Farben für extreme Einkerbung.

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

Meine Kommentare: Ich habe ständig mit der Art und Weise zu kämpfen, wie 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 stimmen Sie mit Ihrer aktuellen XML/Ihrem aktuellen Code überein.

8
Gauthier

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

Vielleicht eine Wärmekarte in der linken Spalte mit helleren Farben, die auf eine tiefere Einkerbung hinweisen? Stellen Sie den Rand auf eine feste Größe ein, mit einer Visualisierung wie der, die Sie haben (erwarten Sie, dass Sie wie bei der Einrückung von links nach rechts gehen), die dynamisch den gesamten Raum verwendet, der gemäß der durch die DOM-Tiefe bestimmten maximalen Einrückung angegeben wird.

Wenn Sie bereit wären, in die Editorregion zu verzweigen, würde ich etwas sehr Ähnliches vorschlagen, jedoch als Hintergrund für das Dokument. Der schattierte Bereich wäre dort, wo Leerzeichen wären, wenn der Einzug aktiviert wäre. In diesem Fall würde ich eine feste, helle Farbe verwenden, die im Kontrast zur Texthervorhebung steht.

5
jimp

Keine schlechte Idee, aber den linken Rand referenzieren zu müssen, um meine Blöcke klar 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 zu sehen, die sie zum Einrücken verwenden, können Sie ihnen einfach die Leerzeichen zeigen.

Ich spreche nicht von visuellen Sonderzeichen wie Absatzmarkierungen, sondern nur von Highlights. Leerzeichen in Gelb, Tabulatoren in Grün (oder was auch immer)

Für das Rand-/Verschachtelungsproblem können Sie den Rand für jeden Block einfach 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:

sample xml showing moving left margin and highlighted whitespace

3
Justin Ohms

jGRASP verwendet dazu einen visuellen Marker am Rand:

enter image description here

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 ein bestehender Editor das macht.

3
ash

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

Es gibt verschiedene Möglichkeiten, in Vim "Code zu falten". Eine davon basiert auf Syntax-Faltregeln. Wenn dies erledigt ist, kann der Code unter Verwendung einer verschachtelten Umrissstruktur gefaltet werden, und die "FoldColumn" kann verwendet werden, um eine grafische (tatsächlich "zeichenbasierte" Darstellung mit '|' und '-' Zeichen) der "Faltstufe" zu geben. .

Die Foldcolumn kann die Verschachtelungsdarstellung unabhängig von der Foldmethod angeben, aber die syntaxbasierte Methode ist wahrscheinlich diejenige, die für das, was Sie wollen, geeignet wäre. Ich bin mir nicht sicher, ob es irgendwo vorgefertigte syntaxbasierte Faltregeln für XML gibt.

2
Herbert Sitz

Warum nicht Klammern öffnen und schließen?

  1. Einrückung bedeutet Eindämmung: (und) bedeuten genau das für Programmierer.
  2. (und) sind jeweils ein einzelnes Zeichen: Der linke Balken bleibt sehr dünn.
  3. Leere Elemente sind leicht zu erkennen: Verwenden Sie () in derselben Zeile.
  4. Der Inhalt eines Elements benötigt keinen visuellen Hinweis: Ein Leerzeichen ist viel besser.
  5. Die Cursorposition rechts kann mit dem enthaltenen Block links übereinstimmen: Fügen Sie den Zeichen in der Spalte mit (und) dynamisch eine Farbe hinzu.
  6. Sie könnten es mit <und> mehr XML-ish machen, was aus der Ferne besser aussieht.
2
Ando

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 anscheinend festgelegt haben. 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, im Vergleich zu Geschwistern, die auf dem Weg dorthin sind.

Achten Sie bei der Implementierung von farbtonbasierten Elementen auf Farbenblindheit und wählen Sie entweder Farben aus, die universell unterscheidbar sind, oder bieten Sie einige Optionen zur Auswahl.

1
Phil Miller

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

Bei der Verwendung einer Art Editor ist es jedoch 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ört. Sie können den Baum sogar hervorheben (von welchen Elementen ist er ein Kind). Ich denke, dass dies ein separates Thema ist, das angesprochen und überlegt werden muss und mehr Einfluss darauf hat, wie die Benutzer ihre Erfahrungen mit dem Editor bewerten.

1
Inca

Möglicherweise könnten Sie eine reduzierte 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 zu geben. Scheint mir ein Gewinn zu sein.

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

0
m4tt1mus

Eine Option, die in Verbindung mit den anderen bisherigen 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) führen häufig ähnliche Aktionen aus, jedoch in einer Statusleiste.

0
Peter Taylor