Quali sono gli svantaggi delle tabulazioni elastiche? [chiuso]

82

Guarda qui: una tipica guerra santa su schede vs spazi .

Ora guarda qui: tabstops elastici . Tutti i problemi risolti e un sacco di nuovi comportamenti molto utili aggiunti.

Letabulazionielastichesonoanchemenzionatenelladiscussioneditabsvsspaces?Perchèno?Cisonodeglisvantagginell'ideaelasticaditabstopcosìgravichenessunolihamaiimplementatiinuneditorpopolare?

EDIT:miscusoperaverdatotroppaenfasia"perché non vengono citati". Non era proprio quello che intendevo; quella domanda è forse anche fuori tema. Ciò che intendo veramente è, quali sono i maggiori inconvenienti di questo che impediscono l'adozione più ampia di un'idea ovviamente benefica? (in un mondo ideale in cui tutto lo supporta già)

(Risulta che c'è già una richiesta su Microsoft Connect per un Implementazione di Visual Studio di tabulazioni elastiche e una richiesta in Eclipse . Inoltre, c'è una domanda che richiede altri editor che implementano tabulazioni elastiche )

    
posta Roman Starkov 28.02.2012 - 11:46
fonte

12 risposte

32

Holy Wars sono soggettivi

Le tabulazioni elastiche di Nick sono un concetto incredibile che potrebbe aiutare molte persone a concordare una soluzione praticabile, anche se dubito strongmente che finirebbe interamente questa guerra santa: dopotutto, è anche un Questione di gusti e molti programmatori non si sposteranno di un millimetro dalla loro posizione in merito, anche a costo di compromessi. Quindi questa sarebbe una prima ragione.

Ad esempio, molte persone sul lato "spazi" continueranno a non piacergli poiché richiede un ulteriore elemento logico nel tuo software per un rendering decente (ad esempio, semplicemente visualizzando un changeset nel tuo SCM's webview.

Problemi di implementazione

Ma la ragione più ovvia è solo la sua barriera tecnica all'entrata : è un concetto fondamentalmente diverso da ciò che è stato implementato per un numero di anni (se non decenni) in IDE e redattori di testi. Richiederebbe la riscrittura di alcuni di essi per elaborare linee in una fasion abbastanza diversa, il che rende difficile per i sistemi più vecchi e più grandi che hanno una maggiore probabilità di soffrire di un accoppiamento profondo e stretto nel loro codice di elaborazione della linea. È, tuttavia, molto più facile da fare quando si inizia da zero (si pensi alla demo di Nick o di Go 's tabwriter pacchetto).

Per un aneddoto personale, ricordo di aver contattato l'autore qualche tempo fa per chiedere se ci fosse qualche supporto per emacs in vista, e in questo caso particolare ha menzionato questo come motivo per cui non è banale. Ha anche chiesto aiuto alla comunità per aiutare a implementare questa funzione e portarla alle masse.

Ci teniamo abbastanza?

Una terza ragione, è che alcuni sviluppatori non sono così appiccicati alla questione e non si preoccupano così tanto che farebbero il possibile per sostenere lo sforzo. Nella maggior parte dei casi, il conflitto spazi-vs-tabs non è un blocco di business, quindi non c'è molta spinta dietro al problema.

Se lo vuoi, dovrai lottare per questo. Che è fattibile nel software open source. E se cambi abbastanza di questi, quelli a codice chiuso dovranno correre il rischio di perdere alcuni dei loro utenti, se mai una piccola parte di esso.

Quindi, se lo vuoi, dai una mano a Nick.

    
risposta data 28.02.2012 - 17:18
fonte
35

Molte volte ho dovuto combattere con un word processor per far apparire il documento nel modo che preferisco senza alcune regole automatiche nascoste che controllano il posizionamento delle mie parole. Non voglio passare un secondo a cercare di capire perché l'editore insiste nel mettere quelle parole lì.

    
risposta data 28.02.2012 - 14:12
fonte
27

Questa è la prima volta che ne ho sentito parlare. Non sono sicuro se siano una buona idea ma sembrano poco utili dato che abbiamo strumenti (come il rientro) che formattano automaticamente il codice già.

Che cosa accade quando apro i tuoi abili tabelloni elastici in vim e lo modifichi? La scheda si pulisce automaticamente o ti rimane un problema?

I principali inconvenienti, come li vedo, sono forse la possibilità di rompere le differenze, il controllo della versione e non essere compatibili con gli editor che non li supportano. Può essere necessaria molta modifica del codice per supportarli e ci sono cose più importanti della funzione "ancora un'altra scheda per formattare il codice". Dopo tutto, possiamo tutti usare indent che fa tutto quanto sopra se la memoria serve.

    
risposta data 28.02.2012 - 12:04
fonte
13

Per essere onesti, non li trovo così utili una volta superata l'eccitazione iniziale. Ad esempio, non mi piacciono i commenti alla fine di una riga - I always metti i miei commenti su una riga separata. Con questo, le schede elastiche perdono il loro uso principale.

Dopodiché, puoi ancora usarli per allineare argomenti (e parametri) e lunghi elenchi di assegnazioni.

Ma per il primo tendo a rientrare tutti gli argomenti di un livello aggiuntivo e questo funziona perfettamente con me:

void foo(
    int x,
    int y,
    string z
)

E non vedo qualsiasi necessario per cambiarlo.

E per quanto riguarda l'allineamento dei compiti, io non lo faccio. Metto singoli spazi attorno ai compiti, il gioco è fatto. Tendo anche a non raggruppare molti compiti insieme, quindi raramente c'è un problema di leggibilità.

In sintesi, le schede elastiche hanno assolutamente zero utilità per me. Questa è ovviamente una preferenza personale che può variare, ma trovo che funzioni bene e suppongo che la mancanza di supporto per le schede elastiche sia perché le altre persone la pensano allo stesso modo.

Se un editor li implementasse, non li userei ancora.

    
risposta data 28.02.2012 - 17:07
fonte
13

Uno svantaggio è che non funziona se vuoi l'allineamento su un gruppo di linee e quindi il rientro sul successivo, poiché raggruppa i punti di tabulazione delle linee adiacenti.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

Cosa volevo:

def foo( bar,
         xyzzy ):
    wibble()

Per i linguaggi di parentesi graffa questo potrebbe essere un problema minore, poiché di solito è possibile risolvere questo problema mettendo la parentesi aperta su una linea a sé stante (come nell'animazione), ma per i linguaggi sensibili a spazi bianchi, questo diventa rapidamente un dolore, e finisci per dover ricorrere agli spazi.

    
risposta data 28.02.2012 - 20:16
fonte
11

Perché non usiamo solo il carattere di tabulazione verticale (VT, ASCII 11) per indicare l'uso di tabulazioni elastiche? Serve senza scopo in qualsiasi linguaggio di programmazione mainstream, eppure è analizzato come spazio bianco valido in tutti, AFAIK.

Ciò significherebbe che l'uso di tabulazioni elastiche non è più una convenzione esternalizzata (ad esempio "questo file è stato formattato con tabulazioni elastiche, si prega di accenderlo") ma qualcosa a cui si opta per caso caso.

Gli editor di testo esistenti di solito visualizzano un glifo o un singolo spazio al posto di una scheda verticale. Questo non è l'ideale, ma un piccolo prezzo da pagare, IMO.

    
risposta data 12.01.2013 - 00:12
fonte
10

Non vengono menzionati perché non sono implementati nella maggior parte degli IDE di editor di testo; sono una novità poco utile in un progetto.

Gli spazi sono stati usati per organizzare la programmazione sin dai tempi delle schede perforate. Le schede sono arrivate e qualcuno ovviamente ha pensato che fossero una buona idea (si sbagliavano: p).

Nei giorni in cui la maggior parte degli editor moderni può convertire automaticamente le schede in spazi ... sono piuttosto inutili.

Dovendo installare ancora un altro strumento per gestire qualcosa di così banale come le schede e gli spazi certamente non mi piacciono, e non penso che lo farebbe alla maggior parte dei miei colleghi.

    
risposta data 28.02.2012 - 11:52
fonte
4

Penso che troverebbero molto utile se gli IDE li supportassero (Microsoft!). Una volta che le persone hanno scoperto che potevano schiaffeggiare le loro fioriere sul lato e averle ben leggibili, lo faranno. Potresti aggiungere più commenti al codice sorgente all'improvviso (che può essere solo una buona cosa).

Suppongo che potremmo aggiungere anche commenti "tooltip" all'elenco di "sarebbe bello se ...", così i tuoi blocchi di commenti più grandi potrebbero essere nascosti e visualizzati facilmente quando necessario. Forse potremmo anche avere blocchi di commento che fanno parte della documentazione (non roba di tipo sandcastle, snippet di documentazione leggibile dall'utente che sono stati incorporati nel codice, non solo le intestazioni del metodo)

Svantaggi: potrebbe far sembrare cattiva la tua fonte se un gruppo di linee sembra che siano state cambiate quando solo 1 è stato modificato (se l'editor ha salvato il file con le schede convertite in spazi). Oppure, se la scheda elastica è stata implementata con un singolo carattere (o più probabilmente, 2 tabstops), la visualizzazione della fonte al di fuori dell'editor potrebbe sembrare brutta.

Penso che l'idea mi piaccia, "tab tab" alla fine di una riga elastica il blocco dei commenti e allinea tutti i commenti sulle righe successive (che hanno la spaziatura doppia) di conseguenza.

    
risposta data 28.02.2012 - 12:09
fonte
3

Ecco come la vedo io: se la maggior parte degli strumenti popolari supportava già le tabulazioni elastiche, molte persone le usavano. Lo stesso è accaduto con la modalità di navigazione / modifica di vi, con l'evidenziazione della sintassi e in seguito con Intellisense. In ogni caso, la saggezza consolidata era che non è utile o non necessario, ma è stato implementato e ha preso il volo.

Le tabulazioni elastiche, naturalmente, hanno un impatto relativamente basso. La maggior parte delle persone è sufficientemente soddisfatta dello status quo e quindi non importa. Un ragionamento simile si applica a molte situazioni in cui alcune persone sono semplicemente felici di ciò che hanno e non vedono alcun motivo per passare a qualcosa di più avanzato. In altre parole, il problema più grande con i tabstops elastici è lo stesso di quasi ogni altra buona idea: ha bisogno di guadagnare trazione.

Ma ciò non significa che la funzione non possa essere adottata in modo incrementale. Ogni singolo linguaggio di programmazione è stato adottato in modo incrementale, anche se un intero team richiede un nuovo compilatore e un nuovo IDE per iniziare a usarlo. Lo stesso vale per ogni singola architettura hardware e molti altri esempi. Non è inoltre il caso che la mancanza di integrazione con gli strumenti esistenti sia un ostacolo allo spettacolo: lo stesso è vero, ad esempio, del "formato unificato diff", che ha sostituito progressivamente un precedente formato meno leggibile che è stato tuttavia compreso dagli strumenti automatici (come patch). Questi strumenti sono stati aggiornati nel corso del tempo.

Apprezzo i problemi di interoperabilità che altri hanno menzionato, ma nonostante ciò, sicuramente ci saranno squadre (come la mia) che adotterebbero questo senza esitazione, nella nostra interezza. Strumenti esterni come la diffusione, la fusione, ecc. Inizialmente non lo supportano, ma faremmo la nostra parte per incoraggiare i venditori a includere la funzionalità. È così che sono sempre stati fatti progressi. Richiede alcuni dolori per un periodo transitorio temporaneo, ma alla fine ne vale la pena.

    
risposta data 28.02.2012 - 16:21
fonte
2

Il problema più grande che avrei con esso è la spaziatura incoerente in tutta la documentazione. So che come programmatore mi infastidirebbe vedere un'annotazione o un'istruzione in rientranza "standard" e quindi notare in diverse rientranze. So che personalmente mi piace vedere tutte le mie parentesi graffe allineate in tutta la documentazione, non solo nel blocco di codice che sto guardando.

In generale penso che sia comunque una buona idea, ma personalmente, non mi piacerebbe.

    
risposta data 28.02.2012 - 15:32
fonte
1

Ho appena provato l'implementazione di tablops elastico di jEdit, che funziona incredibilmente bene con i linguaggi di programmazione con cui ho familiarità (principalmente HTML / XML e linguaggi simili a C). Con il codice Python, tuttavia, ecco come viene reso (spazi usati al posto delle schede per illustrare come le cose si allineano):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

Per un linguaggio come Python che si basa sulla spaziatura, questo è un deal-breaker a meno che non si disabiliti la funzionalità fornita da tabulazioni elastiche. Editori come Vim ed Emacs rendono semplice disabilitare molti tipi di funzionalità se si conosce il nome dell'opzione e come disabilitarlo, ma questa funzionalità dovrebbe essere disabilitata per il codice come sopra.

Detto questo, è fantastico per x86 ASM, C, C ++, Go, XML, HTML e altri che non si affidano troppo agli spazi:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

Dirò che i dialoghi Lisp come Scheme hanno le loro convenzioni che renderebbero anche i tabstops elastici il codice "brutto". Se cambio le mie impostazioni tabstop in modo che corrispondano alla convenzione di 2 colonne e inserisca tabstop in punti insoliti (tra una funzione e i suoi argomenti):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

vs. il più leggibile:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

Certo, questo non è così male come l'esempio di Python, ma sicuramente riduce la leggibilità del codice. Mentre mi piace molto la funzionalità quando si codifica in qualcosa come C # o C ++, aborrisco la funzionalità quando si codifica in una lingua come Python o Scheme in cui gli spazi bianchi sono funzionali e / o visivamente utili. Le tabulazioni elastiche sono state create appositamente per essere utili senza richiedere un'utilità di indentazione separata, ma chiaramente non sono pensate per tutti i linguaggi di programmazione.

    
risposta data 05.10.2015 - 03:52
fonte
0

Emacs gestisce già il rientro in presenza di parentesi non chiuse e allinea automaticamente wilma con fred . Non ho idea del perché Eclipse non faccia lo stesso. Ok, ho un'idea, ma non è affatto semplice.

Potresti ottenere Emacs per allineare anche il commento, senza troppi problemi, ma AFAIK nessuno, ma tu lo hai mai voluto.

    
risposta data 28.02.2012 - 18:44
fonte

Leggi altre domande sui tag