In che modo un editor di codice può suggerire in modo efficace a livello di annidamento del codice, senza utilizzare il rientro? [chiuso]

Ho scritto un editor di testo XML che fornisce 2 opzioni di visualizzazione per lo stesso testo XML, uno rientrato (virtualmente), l'altro giustificato a sinistra. La motivazione per la vista giustificata a sinistra è di aiutare gli utenti a "vedere" i caratteri degli spazi bianchi che stanno usando per il rientro del testo in chiaro o del codice XPath senza interferenze dal rientro che è un effetto collaterale automatizzato del contesto XML.

Voglio fornire indizi visivi (nella parte non modificabile dell'editor) per la modalità giustificata a sinistra che aiuterà l'utente, ma senza essere troppo elaborata.

Ho provato a usare solo le linee di collegamento, ma sembrava troppo affollato. Il meglio che ho trovato finora è mostrato in uno screenshot simulato dell'editor qui sotto, ma sto cercando alternative migliori / più semplici (che non richiedono troppo codice).

[Modificare]

Prendendo l'idea della mappa di calore (da: @jimp) ottengo questa e 3 alternative - etichettate a, bec:

La sezione seguente descrive la risposta accettata come una proposta, riunendo idee da una serie di altre risposte e commenti. Poiché questa domanda è ora wiki della community, non esitare ad aggiornarlo.

NestView

Il nome per questa idea che fornisce un metodo visivo per migliorare la leggibilità del codice nidificato senza utilizzare il rientro.

Linee di contorno

Il nome per le linee diversamente ombreggiate all'interno di NestView

L'immagine sopra mostra NestView utilizzato per aiutare a visualizzare uno snippet XML. Sebbene XML sia utilizzato per questa illustrazione, qualsiasi altra sintassi del codice che utilizza l'annidamento potrebbe essere stata utilizzata per questa illustrazione.

Una panoramica:

1. Le linee di contorno sono ombreggiate (come in una mappa di calore) per comunicare il livello di annidamento

2. Le linee di contorno sono inclinate per mostrare quando un livello di annidamento viene aperto o chiuso.

3. Una linea di contorno collega l'inizio di un livello di annidamento alla fine corrispondente.

4. La larghezza combinata delle linee di contorno offre un'impressione visiva del livello di annidamento, oltre alla mappa di calore.

5. La larghezza di NestView può essere ridimensionabile manualmente, ma non dovrebbe cambiare quando cambia il codice. Le linee di contorno possono essere compresse o troncate per mantenere questo risultato.

6. Le righe vuote vengono talvolta utilizzate come codice per suddividere il testo in blocchi più digeribili. Tali linee potrebbero innescare comportamenti speciali in NestView. Ad esempio, è possibile ripristinare la mappa di calore o utilizzare una linea di contorno del colore di sfondo o entrambi.

7. È possibile evidenziare una o più linee di contorno associate al codice attualmente selezionato. La linea di contorno associata al livello di codice selezionato verrebbe maggiormente enfatizzata, ma anche altre linee di contorno potrebbero 'illuminarsi' in aggiunta per aiutare a evidenziare il gruppo nidificato contenente

8. Diversi comportamenti (come la piegatura del codice o la selezione del codice) possono essere associati al clic / doppio clic su una linea di contorno.

9. Parti diverse di una linea di contorno (bordo anteriore, medio o finale) possono avere comportamenti dinamici diversi associati.

10. Le descrizioni comandi possono essere visualizzate su un evento al passaggio del mouse su una linea di contorno

11. NestView viene aggiornato continuamente man mano che il codice viene modificato. Laddove la nidificazione non sia ben bilanciata, è possibile formulare ipotesi in merito alla conclusione del livello di nidificazione, ma le linee di contorno temporanee associate devono essere evidenziate in qualche modo come avvertenza.

12. È possibile supportare i comportamenti di trascinamento delle linee di contorno. Il comportamento può variare in base alla parte della linea di contorno trascinata.

13. Funzionalità comunemente presenti nel margine sinistro come la numerazione delle linee e l'evidenziazione del colore per errori e cambiamenti di stato potrebbero sovrapporre NestView.

Funzionalità aggiuntiva

La proposta affronta una serie di questioni aggiuntive: molte sono al di fuori dell'ambito della domanda originale, ma un utile effetto collaterale.

Collega visivamente l'inizio e la fine di una regione nidificata

Le linee di contorno collegano l'inizio e la fine di ciascun livello nidificato

Evidenziando il contesto della linea attualmente selezionata

Quando viene selezionato il codice, è possibile evidenziare il livello del nido associato in NestView

Differenziazione tra regioni di codice allo stesso livello di nidificazione

Nel caso di XML è possibile utilizzare tonalità diverse per spazi dei nomi diversi. I linguaggi di programmazione (come c #) supportano regioni denominate che potrebbero essere utilizzate in modo simile.

Dividere le aree all'interno di un'area di nidificazione in diversi blocchi visivi

Le linee extra vengono spesso inserite nel codice per facilitare la leggibilità. Tali linee vuote potrebbero essere utilizzate per ripristinare il livello di saturazione delle linee di contorno del NestView.

Vista codice multi-colonna

Il codice senza rientro rende più efficace l'uso di una vista a più colonne poiché è meno probabile che siano necessari il ritorno a capo automatico o lo scorrimento orizzontale. In questa vista, una volta che il codice ha raggiunto il fondo di una colonna, scorre nel successivo:

L'uso oltre a fornire semplicemente un aiuto visivo

Come proposto nella panoramica, NestView potrebbe fornire una gamma di funzioni di modifica e selezione che sarebbero sostanzialmente in linea con quanto previsto da un controllo TreeView. La differenza fondamentale è che un tipico nodo TreeView ha 2 parti: un espansore e l'icona del nodo. Una linea di contorno NestView può avere fino a 3 parti: un apri (inclinato), un connettore (verticale) e una chiusura (inclinata).

Sulla rientranza

NestView viene presentato insieme a complementi di codice non indentati, ma è improbabile che sostituisca la vista di codice indentata convenzionale.

È probabile che qualsiasi soluzione che adotti un NestView fornirà un metodo per passare senza interruzioni tra viste di codice indentate e non indentate senza influire sul testo del codice stesso, inclusi i caratteri di spazi bianchi. Una tecnica per la vista rientrata sarebbe la "formattazione virtuale", in cui viene usato un margine sinistro dinamico al posto di caratteri di tabulazione o spazio. Gli stessi dati a livello di annidamento utilizzati per il rendering dinamico di NestView potrebbero anche essere utilizzati per una vista rientrata dall'aspetto più convenzionale.

Stampa

Il rientro sarà importante per la leggibilità del codice stampato. Qui, l'assenza di caratteri tab / space e un margine sinistro dinamico significa che il testo può avvolgere sul margine destro e mantenere comunque l'integrità della vista rientrata. I numeri di riga possono essere utilizzati come marcatori visivi che indicano dove il codice è racchiuso tra le parole e anche la posizione esatta del rientro:

Schermo immobiliare: piatto contro rientro

Rispondere alla domanda se NestView utilizza preziose proprietà dello schermo:

Le linee di contorno funzionano bene con una larghezza uguale alla larghezza del carattere dell'editor di codice. Una larghezza NestView di 12 caratteri può quindi ospitare 12 livelli di annidamento prima che le linee di contorno vengano troncate / compresse.

Se una vista rientrata utilizza 3 larghezze di carattere per ciascun livello di annidamento, lo spazio viene risparmiato fino a quando l'annidamento non raggiunge 4 livelli di annidamento, dopo questo livello di annidamento la vista piatta presenta un vantaggio salvaspazio che aumenta con ogni livello di annidamento.

Nota: un rientro minimo di 4 caratteri di larghezza è spesso raccomandato per il codice, tuttavia XML spesso gestisce con meno. Inoltre, la formattazione virtuale consente di utilizzare meno rientri poiché non sussiste il rischio di problemi di allineamento

Di seguito è mostrato un confronto delle 2 viste:

Sulla base di quanto sopra, è probabilmente corretto concludere che la scelta dello stile di visualizzazione si baserà su fattori diversi dal settore immobiliare dello schermo. L'unica eccezione è quella in cui lo spazio dello schermo è un premio, ad esempio su un netbook / tablet o quando sono aperte più finestre di codice. In questi casi, NestView ridimensionabile sembrerebbe essere un chiaro vincitore.

Casi d'uso

Esempi di esempi reali in cui NestView può essere un'opzione utile:

1. Dove lo schermo immobiliare è un premio

   un. Su dispositivi come tablet, blocchi note e smartphone

   b. Quando si mostra il codice sui siti Web

   c. Quando più finestre di codice devono essere visibili contemporaneamente sul desktop

2. Laddove un rientro consistente degli spazi bianchi nel testo all'interno del codice è una priorità

3. Per la revisione di codice profondamente nidificato. Ad esempio, dove le lingue secondarie (ad esempio Linq in C # o XPath in XSLT) potrebbero causare livelli elevati di annidamento.

Accessibilità

Le opzioni di ridimensionamento e colore devono essere fornite per aiutare le persone con disabilità visive e anche per soddisfare le condizioni ambientali e le preferenze personali:

Compatibilità del codice modificato con altri sistemi

Una soluzione che incorpora un'opzione NestView dovrebbe idealmente essere in grado di eliminare i caratteri di tabulazione e spazio (identificati come aventi solo un ruolo di formattazione) dal codice importato. Quindi, una volta rimosso, il codice potrebbe essere reso in modo ordinato in entrambe le viste giustificate a sinistra e rientrate senza modifiche. Per molti utenti che si affidano a sistemi come la fusione e strumenti diff che non sono consapevoli degli spazi, questa sarà una delle maggiori preoccupazioni (se non uno stop-show completo).

Altre opere:

Visualizzazione del markup sovrapposto

Una ricerca pubblicata da Wendell Piez , datata 2004, affronta il problema della visualizzazione del markup sovrapposto, in particolare LMNL . Ciò include la grafica SVG con significative somiglianze con la proposta NestView, come tale, sono riconosciute qui.

Le differenze visive sono chiare nelle immagini (sotto), la distinzione funzionale chiave è che NestView è inteso solo per XML o codice ben nidificati, mentre la grafica di Wendell Piez è progettata per rappresentare la nidificazione sovrapposta.

La grafica sopra è stata riprodotta - con gentile concessione - da http://www.piez.org

fonti:

1. Verso il markup ermenutico
2. Mezzi passi verso LMNL

Ho cercato di rispondere alla mia domanda qui, ma questo sta incorporando l'idea della mappa di calore di @jimp e anche l'idea di "renderlo più XML-ish" da @Andrea:

Eventualmente, i colori nella mappa di calore insieme alle linee angolari aiutano a disegnare l'occhio tra i tag di inizio e fine; la rimozione dei separatori di linea orizzontale migliora il "flusso" dall'inizio alla fine. Quando l'utente seleziona con un elemento, la parte corrispondente nella mappa di calore può essere evidenziata in qualche modo, forse con un bordo luminoso (come mostrato).

Modifica Ho deciso di procedere con questo, probabilmente ci saranno opzioni utente per i colori. Uno screenshot 'pronto per la produzione':

E per confronto ... la vista rientrata alternativa:

Modifica ora, per il caso più nidificato: testare le mie abilità di disegno ...

Un'idea potrebbe essere quella di provare ad aggiungere 3D al testo. Aumenta / diminuisci la dimensione del carattere in base al livello a cui si trova.

Ad esempio, questo codice:

Assomiglierebbe a questo:

Potrebbe essere fastidioso lavorare perché perde l'allineamento fisso della dimensione del testo su diversi livelli. Un'altra idea; cambia la saturazione di ogni livello:

Quanto bene regge qualcosa di veramente profondo? Non sono sicuro...

In realtà mi piace molto la tua idea di visualizzazione di grondaie; è facile raggruppare le cose. Forse combinato con una di queste idee sembrerà ancora migliore, o molto più scadente. ;)

Qualche tempo fa ho fatto una mappa di calore che mostrava l'ambito in C. Potrebbe essere divertente guardare il brainstorming:

Allineato a sinistra:

Basta modificare la tua idea originale e passare dai quadrati alle capsule. Penso che queste versioni (compresa la tua originale) siano più facili da leggere perché sono meno complesse di quella che mostra l'annidamento attraverso l'annidamento degli elementi di visualizzazione. Penso che gli elementi dell'albero trasmettano le informazioni in un modo più semplice e intuitivo.

Penso che la sinistra sia ottima per mostrare direttamente il rientro, mentre la destra è migliore nel trasmettere una relazione nidificata.

La mia idea:

L'annidamento sembra più un annidamento. La larghezza orizzontale di ogni strato non deve essere così ampia.

Adoro l'idea. Il mio suggerimento di mantenere "occupato" sarebbe di usare i gradienti invece dei quadrati. Ridurrebbe le linee. Forse colori diversi per un rientro estremo.

Direi che tutto quello che hai è fantastico, anche se un po 'complicato per i miei gusti.

I miei commenti: sono stato costantemente alle prese con il modo in cui l'IDE di Visual Studio esegue il rientro. Mi piacerebbe usare qualcosa di simile o una variazione.

Quindi immagina quel collegamento senza le linee e in linea con il tuo codice / codice xml corrente.

Dato che hai detto che la visualizzazione deve esistere nel margine non modificabile (a sinistra?), Credo che significhi che la visualizzazione non può essere mescolata o nascosta dietro il codice.

Forse una mappa di calore nella colonna di sinistra, con colori più luminosi che indicano una rientranza più profonda? Rendi il margine di dimensioni fisse, con una visualizzazione come quella che hai (aspettati di andare da sinistra a destra come il rientro) che utilizza in modo dinamico tutto lo spazio dato in base al rientro massimo determinato dalla profondità del DOM.

Se tu fossi disposto a diramare nella regione dell'editor, suggerirei qualcosa di molto simile, ma come sfondo del documento. L'area ombreggiata sarebbe dove sarebbero gli spazi bianchi se il rientro fosse abilitato. In questo caso, utilizzerei un colore chiaro, solido, in contrasto con l'evidenziazione del testo.

jGRASP lo fa usando un marcatore visivo a margine:

Riconosce persino quando si utilizza un loop e utilizza un diverso tipo di linea per rappresentare quel loop interno.

Ho pensato di sottolineare come fa un editor esistente.

Non è una cattiva idea ma dover fare riferimento al margine sinistro per vedere chiaramente i miei blocchi potrebbe diventare un po 'fastidioso. Non sta nemmeno pensando al settore immobiliare dello schermo o a come potrebbero apparire le cose se la struttura diventa molto profonda.

Poiché la motivazione è aiutare gli utenti a "vedere" i caratteri degli spazi bianchi che stanno usando per il rientro, potresti semplicemente mostrare loro i caratteri degli spazi bianchi.

Non sto parlando di speciali personaggi visivi come marcatori di paragrafo, ma solo momenti salienti. Spazi in giallo, schede in verde (o qualsiasi altra cosa)

Per il problema del margine / annidamento, puoi semplicemente spostare il margine per ciascun blocco. Non c'è nulla che dica che il margine deve essere una linea retta.

Sono sicuro che questa non è una nuova idea.

Qualcosa come questo:

Perché non aprire e chiudere le parentesi?

1. Il rientro significa contenimento: (e) significano esattamente questo per i programmatori.
2. (e) sono ciascuno un singolo carattere: la barra di sinistra rimarrà molto sottile.
3. Gli elementi vuoti sono facilmente individuabili: use () sulla stessa riga.
4. Il contenuto di un elemento non ha bisogno di un indizio visivo: uno spazio vuoto è molto meglio.
5. La posizione del cursore a destra può essere abbinata al blocco contenitore a sinistra: aggiungi dinamicamente un colore ai caratteri nella colonna con (e)
6. Potresti renderlo più XML usando <e>, che sembrano migliori a distanza.

Vim può già fare qualcosa di simile, anche se non abbastanza carino.

Esistono vari modi per eseguire la "piegatura del codice" in Vim. Uno di questi si basa su regole di piegatura della sintassi. Al termine, il codice può essere piegato utilizzando una struttura di struttura nidificata e "FoldColumn" può essere utilizzato per fornire una rappresentazione grafica (in realtà "basata sui caratteri" con "|" e "-" caratteri) del "foldlevel" .

Il foldcolumn può fornire la rappresentazione di annidamento indipendentemente dal metodo foldmethod, ma il metodo basato sulla sintassi è quello che sarebbe probabilmente appropriato per quello che vuoi. Non sono sicuro che ci siano regole di piegatura pre-fatte basate sulla sintassi là fuori per xml da qualche parte, immagino che ci possano essere.

Penso che tu sia sulla strada giusta con le opzioni B e C: includi sia la larghezza che la colorazione della mappa di calore. Mi piace l'opzione B più di C al momento, perché è meno invadente (sia ampia e diluita, o stretta e intensa, piuttosto che il blocco molto pesante nel mezzo di C) Uno svantaggio è che con quell'opzione devi ricostruisci l'intero grafico se inserisci un livello da qualche parte. Penso che potresti rendere i blocchi molto più piccoli, 1 o 2 px sarebbero probabilmente sufficienti. Non deve essere molto, deve solo essere distinguibile. Soprattutto quando ci si aspetta che le persone utilizzino l'editor molte volte, è più facile lavorare con effetti discreti e più sottili perché non distraggono così tanto.

Una cosa che è importante quando si utilizza un editor di sorta è però evidenziare l'ambito attuale: quando si seleziona una linea nell'editor, è necessario vedere esattamente quali elementi contiene e dove si ferma. Potresti anche evidenziare l'albero (di quali elementi è figlio). Penso che sia un problema separato che deve essere affrontato e pensato e avrà più influenza su come gli utenti valuteranno la loro esperienza con l'editor.

Una cosa che non ho visto menzionato è ciò che puoi fare con la tonalità in aggiunta all'effetto di saturazione su cui sembra che tu abbia optato per. Il mio consiglio è di cambiare il colore del nido in cui si trova il puntatore. Ciò renderebbe più semplice per l'utente distinguere quali linee fanno parte del nido, rispetto ai fratelli lungo il percorso.

Quando si implementano elementi basati sulla tonalità, tenere presente il daltonismo e selezionare i colori universalmente distinguibili o offrire alcune opzioni tra cui scegliere.

Un'opzione, che finora potrebbe essere utilizzata insieme agli altri suggerimenti, sarebbe quella di utilizzare una descrizione comandi sul margine sinistro che mostra il percorso della linea usando la notazione XPath. Gli strumenti "inspect element" del browser (ad esempio Firebug, quello integrato in Chrome) spesso fanno qualcosa di simile ma in una barra di stato.

Forse potresti avere una vista compressa per la mappa di calore (dal post originale) con solo una colonna di colori e i numeri di profondità. Ciò consentirebbe loro di sapere quanto sono profondi e dare loro più spazio sullo schermo per l'xml. Sembra una vittoria per me.

Sono preoccupato se ci saranno abbastanza differenze di colore per annidare profondamente le cose.