Allineamento verticale: sì o no? [chiuso]

Personalmente, sono dell'opinione che la seconda versione del codice sia marginalmente più leggibile, ma non credo che il fatto di mantenerlo compensi questa leggibilità. Pertanto, utilizzerei solo la seconda versione di questo esempio se fossi abbastanza certo che il codice non cambierebbe.

Preferisco un ibrido:

Name    : Hamt
Version : 0.1.0
Cabal-Version :  >= 1.2
License : BSD3
Author  : Jason Baker

Che è essenzialmente il numero 2 con eccezioni per linee occasionali più lunghe delle linee circostanti - per impedire che la maggior parte delle linee sia distanziata molto più in là.

Risparmia tempo quando lo fai in questo modo:

Name: Hamt
Version: 0.1.0
Cabal-Version: >= 1.2
License: BSD3
Author: Jason Baker

Non è neanche troppo difficile da leggere.

Preferisco il primo, ma senza le schede (che immagino siano gli spazi vuoti); invece un solo spazio vuoto. Per me è più facile leggere quando i dati non sono "simili", come nel caso specifico. Rende anche più difficile (durante la modifica di tali dati) "confondere una riga", cioè quando si hanno tre righe con, diciamo, i numeri di versione. E poi mentre ne stai modificando uno, ne modifichi accidentalmente un altro al suo posto.

Quando i dati sono simili, tuttavia, ha perfettamente senso inserirlo in colonne come nel secondo esempio (solo che non è simile, ma ottieni il punto).

Ecco un'altra variante per i layout di elenchi basati sia sull'esperienza che sull'istruzione da un corso universitario che ho intrapreso sull'interazione uomo-computer e su diversi libri che ho letto su (G) progettazione e grafica dell'interfaccia utente. Lo uso per i dialoghi e quando ho l'energia / tempo, per i CSS (non di solito per il codice però).

          Name : Hamt
       Version : 0.1.0
 Cabal-Version : >= 1.2
       License : BSD3
        Author : Jason Baker

Come tutti gli altri, ha i suoi pro e contro.

Pro:

• Una strong interruzione visiva separa i dati dalle etichette
• Esteticamente gradevole, aspetto grafico professionale (in particolare per file finalizzati e pubblicati)
• I dati sono più vicini all'etichetta, semplificando l'associazione (diminuisce le possibilità di leggere su una riga i dati errati)
• Ideale per i layout della finestra di dialogo

Contro:

• Richiede più tempo per formattare correttamente
• Richiede il riallineamento quando viene aggiunto un nuovo elemento più lungo
• Non è utile per il codice

HTH

Sfortunatamente, essendo una domanda di stile, questa è molto soggettiva e probabilmente avrai molti risultati contrastanti. Inoltre, lo stile da utilizzare dipende in larga misura dall'utilizzo di TAB o spazi.
Per quanto riguarda i miei due centesimi, preferisco una variante della seconda versione. Mi piace di più:

Name            : Hamt
Version         : 0.1.0
Cabal-Version   : >= 1.2
License         : BSD3
Author          : Jason Baker

È la versione più leggibile e facile da usare che ho provato. L'unico vero svantaggio è che devo capire qual è il campo più ampio, e a volte finire per doverli espandere tutti quando uno è troppo ampio (questo di solito accade solo con i CSS). Tuttavia ci sono alcuni punti che devono essere considerati.

In primo luogo, di solito preferisco i TAB rispetto agli spazi, tuttavia l'impostazione TAB attuale varia; ad esempio, sono abituato a TAB a 4 spazi per il codice C (++) o HTML e TAB a 2 spazi per il codice Pascal o Assembler, mentre per alcune cose come i CSS, non ho preferenze per la larghezza del TAB. Questa variazione complica abbastanza le cose, ma poi l'editor che uso getta nelle sue stesse complicazioni. Alcuni editor ti consentono di impostare le impostazioni TAB per lingua, ma alcuni non lo fanno (anche alcuni con profili diversi).

Puoi evitare questa complicazione rinunciando ai TAB a favore degli spazi. Poiché il codice si trova di solito in un font a larghezza fissa, l'uso degli spazi funziona bene, mentre se si stanno formattando campi in un formato, curriculum o altro testo non di codice e si utilizza un carattere proporzionale, sarà necessario TAB per mantenere le cose allineate .

Preferisco i TAB in generale perché anche con il codice a larghezza fissa, trovo frustrante dover passare attraverso diversi spazi per ogni TAB. Ricordo che i vecchi IDE di Borland avevano un'opzione per passare attraverso i TAB (in particolare le intere lunghezze degli spazi bianchi) come un'unica entità invece che come due, quattro, ecc. Ciò ha reso pratico l'inserimento di TAB come spazi, rendendo la navigazione del cursore facile e veloce. Sfortunatamente non ho visto nessun editor moderno di Windows in grado di farlo.

Infine, se gli altri useranno o meno il tuo codice gioca un ruolo importante nella scelta dello stile. Di solito sono l'unico che usa il mio codice, quindi posso formattare tutto secondo i miei gusti senza riguardo per gli editori o le impostazioni degli altri. Se stai lavorando con altri, dovrai tenerne conto poiché dovranno prenderti in considerazione.
In breve, la leggibilità è buona e molto desiderabile, tuttavia le impostazioni e gli editor che voi e altri che hanno bisogno di usare il codice saranno importanti quando prendete una decisione. Se sei da solo, puoi anche usare il formato che è più leggibile. Potrebbe essere necessario abituarsi a usarlo, ma probabilmente a lungo andare a buon fine, soprattutto quando è necessario tornare al codice che hai scritto qualche tempo fa: la leggibilità è importante quanto i commenti nella comprensione di ciò che fa il codice. Se lavori con gli altri, vorrai lavorare insieme per creare una sorta di guida alla progettazione da utilizzare dal team.