Ottimizzazione di un tipo di file per strumenti di confronto

6

Contesto: Sto sviluppando un plugin per lo studio visivo che genera diagrammi a strati. Voglio che lo strumento sia in grado di produrre un output intermedio, che è la rappresentazione dei dati di ciò che viene reso nel diagramma. L'idea è che questi dati serializzati possano poi essere controllati insieme al codice sorgente che consentirebbe agli sviluppatori di vedere più rapidamente come cambia l'architettura tra i commit. Questo potrebbe essere fatto attraverso strumenti diff diff (come git-diff) o uno strumento diff dedicato. Comunque voglio che il formato del file sia ottimizzato per il primo, a causa della loro accessibilità. I dati sarebbero rappresentati come una struttura ad albero di nodi, in cui ogni nodo avrebbe un nome e un elenco di dipendenze (altri nodi rappresentati dal loro percorso + nome).

Domanda: Quando si progetta un formato di file, ci sono cose per quanto riguarda l'interscambio di dati, il formato o la sintassi e la formattazione di questa sintassi (uso di interruzioni di riga per esempio) che renderebbe più facile o più difficile confrontare diverse versioni usando strumenti come < strong> git-diff . Ad esempio, assicurandosi che lo strumento veda un "rinominare" come "rinominare" e non "eliminare" seguito da un "add" non correlato.

    
posta David 03.01.2016 - 23:39
fonte

1 risposta

1

Questa sembra un'idea molto interessante. Puoi crearne uno per C ++ (nudge-nudge)?

Ho già fatto qualcosa di simile a questo come una sorta di test di un uomo povero, sottoposto a supervisione umana in scenari affrettati in cui ho appena emesso file da test eseguiti manualmente al di fuori di CI con i file di output risultanti sottoposti al controllo di versione. Quindi esaminerei le differenze del file per cercare modifiche impreviste (erano nei campi di approssimazione in cui le modifiche non indicavano necessariamente output errati, ma dovevano essere monitorati attentamente).

Posso solo dare alcuni suggerimenti generali senza conoscere i dettagli elaborati, ma il mio suggerimento di base per iniziare sarebbe quello di favorire un formato che sia piatto possibile .

Cioè, evita qualcosa come XML qui. XML può essere ottimo, ma non è necessariamente il più diff friendly o il più facile da leggere. Ci sono modi per ottenere la struttura nidificata che un file XML rappresenti in modo piatto. Ad esempio:

<foo>
   <blah/>
   <bar>
      <baz/>
   </bar>
</foo>
<x>
   <y value="123"/>
</x>

... potrebbe essere rappresentato in modo piatto come:

[foo]
blah

[foo/bar]
baz

[x]
y = 123

... qualcosa di simile a un esempio grezzo. Si può pensare ad una specie di struttura del file system in cui roba in [...] è una directory e le cose di seguito sono come i file all'interno di quella directory. Sarà più facile controllare in questo modo e avere tutto sulla propria linea, individuare facilmente le differenze, ecc.

Il prossimo passo facile è solo ordinare le voci nel file ("directory" al livello principale e "file" all'interno di una directory). Questo darà al tuo formato di file un sacco di stabilità in modo che non riorganizzi solo arbitrariamente il contenuto del file e rovini totalmente il diff, tagliando più linee come modificate del necessario.

Penso che si possa effettivamente fermarsi a questo punto. Se vuoi andare oltre, puoi iniziare a introdurre spazi bianchi extra per lasciare spazio a nuove voci da inserire in una "directory", ad es. (un po 'come un'implementazione di un array array che ha capacità di memoria in eccesso per aggiungere elementi alla fine senza una riallocazione della complessità lineare e trasferimento dei contenuti precedenti), e persino lasciare dietro di sé linee di spazio vuoto "tombstone" che è possibile recuperare quando nuove le cose sono inserite Ciò comporterà la minima quantità di modifiche al file in casi comuni in cambio di grandi cambiamenti in rari casi, anche se penso che sia davvero eccessivo e arriverà con il peso che i tuoi lettori umani devono affrontare con eccesso e apparentemente arbitrario spazi bianchi. È anche molto più complesso dal momento che dovresti ispezionare i file precedenti che hai fatto per modificarli invece di limitarti a sovrascriverli.

L'ordinamento e l'appiattimento del formato è il modo più semplice per ottenere una buona stabilità di un IMO in formato testo per scopi diff. Ultimo ma non meno importante, probabilmente è solo il buonsenso e qualcosa che già conosci in anticipo, ma naturalmente sarebbe bene prendere vari strumenti diff e testare i tuoi output contro di loro.

    
risposta data 04.01.2016 - 07:23
fonte

Leggi altre domande sui tag