Perché alcune lingue consigliano di utilizzare spazi anziché schede? [chiuso]

10

Forse sono solo in questo, ma poche cose mi infastidiscono come le persone che rientrano usando gli spazi piuttosto che le schede. In che modo la digitazione è SpaceSpaceSpaceSpacepiù semplice e intuitiva della digitazione Tab? Certo, la larghezza della linguetta è variabile, ma è molto più indicativa dello spazio di rientro rispetto agli spazi. La stessa cosa vale per il backspacing; backspace una o quattro volte?

Perché lingue come Python raccomandano di usare spazi su schede?

indentation

— Naftuli Kay
fonte

24

È possibile configurare la maggior parte degli editor per inserire spazi invece di schede quando si preme tab. Se non riesci a configurarlo nel tuo editor preferito, hai bisogno di un editor migliore.

— Adam Lear

una cosa, molti editor possono essere configurati per inserire 4-8 spazi quando si preme 'tab', quindi è solo un tasto premere proprio come tab.

— Echo dice che ripristina Monica il

2

Non risponde ancora alla mia domanda. Perché gli spazi anziché le schede? Certo, puoi configurare il tuo editor per inserire spazi anziché tab, ma puoi anche presumibilmente inserire tab con spazi. La domanda è: perché vorresti farlo? Quale possibile beneficio è derivato?

— Naftuli Kay,

4

@Tk Gli spazi sono inequivocabili e le schede possono essere modificate

— Martin Beckett,

3

@TKKocheran, perché le schede fanno cose funky nel tuo output quando le inserisci accidentalmente in una stringa.

— zzzzBov,

15

Coerenza, principalmente.

Inoltre, a volte succede qualcosa che utilizza effettivamente lo spazio bianco - come Python: Dimmi, cosa succederà se eseguo il seguente frammento di codice?

def foo():
    print "a"
    print "b"

Risposta: Otterrai un IndentationError, perché quelle due istruzioni di stampa non sono rientrate allo stesso livello - e quindi non fanno parte dello stesso blocco di codice. (Il primo utilizza una scheda, il secondo tutti gli spazi)

Poi ci sono casi frustranti quando l'editor di uno sviluppatore ha le schede impostate su 8 spazi, e un altro le ha impostate su 4 e qualcuno sta usando 5 per qualche strana ragione ... Potrebbe sembrare perfettamente normale su una workstation, ma poi quando è registrato su SVN e gli altri aggiornamenti, vedranno un disastro orribile.

Quindi questi sono due buoni motivi per essere sempre coerenti, che si tratti di spazi o schede.

Tuttavia, gli spazi consentono un controllo molto maggiore sul rientro rispetto alle schede e non richiedono alcuna configurazione speciale negli editor perché funzioni. (Anche se può essere reso più semplice - ad esempio, in vim, basta usare set expandtabper inserire spazi ogni volta che si preme la scheda)

EDIT: E in modo abbastanza divertente, il sito sembra aver normalizzato le mie schede in spazi in modo che il browser possa visualizzarlo correttamente. Fai clic su "modifica" per visualizzare l'originale, schede incluse;)

— Izkata
fonte

5

I tuoi problemi con le schede (in particolare l'orrido pasticcio SVN) si verificano solo se usi l'editor tabs-to-space nel tuo editor. Se tu e il tuo team accettate di disabilitare l'opzione tab-to-space, una scheda sarà sempre una scheda in qualsiasi vista: quindi è solo una scelta di quanto volete che venga visualizzata nel vostro editor.

— HorusKol,

@HorusKol No, il casino orribile è perché gli spazi e le schede si sono mescolati. Immagino di non averlo reso abbastanza ovvio (vedi la frase solitaria dopo la riga "orribile, orribile disordine"). Quindi gli spazi sono stati fatti per allinearsi bene con le schede quando sono impostati per essere equivalenti a 4 spazi, ma poi quando qualcun altro lo visualizza (sia che siano impostate le schede negli spazi) o no, ottengono un pasticcio.

— Izkata,

4

Vedo - beh, devi impostare una linea guida per il tuo team - o usare costantemente gli spazi O le schede ... in entrambi i casi, le schede-spazi è una cattiva idea a tutto tondo;)

— HorusKol

21

Questo è il motivo per cui considero l'idea di linguaggi significativi per gli spazi bianchi come un difetto di progettazione. Le cose che non riesci a vedere non dovrebbero mai rompere il tuo codice.

— Paul Nathan,

Per la cronaca, concordo con @PaulNathan

— Izkata il

11

Questa è una buona discussione su rientro e spazi bianchi in Python; dall'articolo:

[I] t può essere una buona idea per evitare le schede del tutto, perché la semantica delle schede non è molto ben definita nel mondo dei computer e possono essere visualizzate in modo completamente diverso su diversi tipi di sistemi ed editor. Inoltre, le schede vengono spesso distrutte o erroneamente convertite durante le operazioni di copia e incolla o quando un pezzo di codice sorgente viene inserito in una pagina Web o altro tipo di codice di markup.

Per quanto riguarda il tuo argomento sulla pressione della barra spaziatrice o del tasto backspace 2 o più volte, poiché la maggior parte degli editor di codice sorgente inserirà un numero configurabile di spazi con una singola pressione del tasto Tab e allo stesso modo un-indent, non ci sono più tasti premuti quando usando gli spazi per il rientro.

Per quanto mi riguarda, preferisco gli spazi perché il codice viene sempre visualizzato con la stessa quantità di rientro, sia che lo visualizzi in un IDE, o less, o Blocco note; cioè gli spazi sono più portatili.

— Mike Partridge
fonte

3

ri: "se lo sto visualizzando in un IDE, o meno, o in Blocco note; cioè gli spazi sono più portabili" - questo è il miglior argomento per gli spazi che io abbia mai sentito. Sono un tipo "tabs" me stesso, ma a volte non mi è piaciuto vedere il codice a tabulazione reso in modi inaspettati.

— Aerik,

2

Nell'indentazione Python controlla il flusso del programma ed è quindi vitale.
Se prendi il codice formattato con le schede e lo copi in modo che le schede vengano modificate o perse, la struttura del codice viene distrutta. Gli spazi sono sempre spazi = molto più sicuri.

Se l'usura della barra spaziatrice ti preoccupa, probabilmente l'editor può essere impostato per convertire automaticamente le schede in spazi.

— Martin Beckett
fonte

Sono più preoccupato del tempo sprecato impiegato a scrivere spazio o backspace quattro volte rispetto a una sequenza di tasti per fare entrambe le cose.

— Naftuli Kay,

Sì, ma Python è strano in quel modo. Non ho mai incontrato nient'altro che si preoccupi degli spazi.

— Aerik,

@TKKocheran Oh, questa è la tua vera preoccupazione? Non so come hanno fatto, ma vim al mio lavoro è impostato in modo che il backspace torni all'ultimo tabstop, su più spazi, in modo completamente trasparente

— Izkata

Potresti scaricare .vimrcper me :)

— Naftuli Kay,

1

@TKKocheran Lo ha trovato: è giusto set softtabstop=4, e sia TAB che BACKSPACE useranno 4 spazi come tab. (Bene, per ogni tabstop, trattando la larghezza come 4 spazi)

— Izkata,

2

Gli spazi devono sempre essere utilizzati, poiché le schede da sole non sono sufficientemente flessibili per molti stili e la combinazione di schede e spazi (quasi) produce sempre un pasticcio assoluto.

Per un esempio di uno stile che generalmente necessita di spazi, prendi in considerazione qualcosa come:

call_some_function(parameter1,
                   parameter2,
                   parameter3,
                   parameter4,
                   parameter5,
                   parameter6,
                   parameter7);

A meno che tu non sia disposto a rinominare tutte le tue funzioni in modo che siano esattamente un multiplo delle dimensioni della scheda (meno una per la parentesi), semplicemente le schede non lo faranno.

Per quanto riguarda la miscelazione di schede e spazi, quasi immediatamente ti imbatti in un grave problema: le schede non vengono costantemente espanse allo stesso modo. Alcuni software considerano una scheda equivalente a un numero specifico di spazi. Un altro software espanderà una scheda modulo un numero specifico di spazi - ad esempio, un elemento dopo una scheda inizierà sempre da un numero di colonna che è un multiplo di (diciamo) 8.

Anche se puoi assicurarti che gli spazi non si mescolino con le tue schede, hai ancora un problema: le schede giocano male anche con caratteri a larghezza variabile. Questo problema si presenta quando (ad esempio) si desidera allineare i commenti finali:

a.m = 9;   // this is the slope
a.i = 4;   // this is the intensity
a.x = 1;   // this is the x-intercept

Allo stato attuale, tutti si allineano perfettamente. Visto con un carattere a larghezza variabile, tuttavia, le cose si fanno brutte. Con gli spazi, i commenti possono (spesso verranno) leggermente allineati erroneamente. Con le schede, tuttavia, il disallineamento diventa spesso abbastanza radicale:

a.m = 9;          // this is the slope
a.i = 4;  // this is the intensity
a.x = 1;          // this is the x-intercept

Improvvisamente la piccola differenza di larghezza tra 'i' e 'm' o 'x' nel nostro font a larghezza variabile è stata ingrandita di un intero punto di tabulazione.

La linea di fondo è che quasi ogni cambiamento nel modo in cui visualizzi il codice con le schede, non importa quanto apparentemente banale, può e di solito produrrà un pasticcio illeggibile.

Per rispondere alle tue altre domande: altri l'hanno già sottolineato, ma non riesco a immaginare nessuno in un editor di programmazione (o molto altro) che usi effettivamente la barra spaziatrice per inserire gli spazi, quindi la tua domanda su "digitare spacespacespacespace" è irrilevante perché nessuno lo fa comunque. Allo stesso modo con il back-spacing: è difficile immaginare un editor che richiederebbe di premere BkSpcquattro volte per passare a un tab stop precedente, quindi (di nuovo) la domanda è irrilevante.

In conclusione: le schede vanno bene se tu (e solo tu) guarderai mai il tuo codice e lo farai solo con un singolo editor che non riconfigurerai mai (affatto!) Tali condizioni, tuttavia, sono così vicine all'impossibile da imporre che esiste una sola risposta ragionevole: non utilizzare mai le schede.

— Jerry Coffin
fonte

1

Vedo che dici "i caratteri proporzionali rompono sia gli spazi che le schede ma peggiorano le schede, quindi usa gli spazi". Perché non usare i tabstops elastici? nickgravgaard.com/elastictabstops

— amara,

@sparkleshy: è una buona idea, ma non fa differenza per il codice reale e non lo farà fino a quando tutti (o almeno la stragrande maggioranza dei) editor reali lo includono già.

— Jerry Coffin,

... lo so: '(- beh, un po'. Puoi ancora usare un editor supportato da spazi (come il tasto tab dovrebbe essere se stai usando spazi) ma finge che siano tabstop elastici; rende la gestione degli spazi più facile

— amara,

2

Se stai programmando in caratteri di larghezza proporzionale, beh, hai molti più problemi di cui solo le schede di cui preoccuparti ...

— Brian Knoblauch,

1

@BrianKnoblauch: come persona che usa il carattere eurofurence, non sono d'accordo. Le uniche cose che mi causano problemi sono gli spazi. Naturalmente ha anche a che fare con il mio stile di rientro, che non deve mai differire di più di una scheda tra le righe. Supponendo che avrò mai i tabs elasticizzati, il mio codice sarà ancora migliore.

— Magus,

2

Il grosso problema è l'incoerenza della larghezza della "scheda" a volte vengono visualizzati come quattro spazi a volte otto. In molti editor puoi impostarli in modo che siano compresi tra 1 e 9 spazi.

Quindi questo trasforma un semplice editor WYSWYG in ciò che vedi è ciò che qualcun altro potrebbe ottenere.

È un problema particolare per Python, ma è anche un problema in una qualsiasi delle lingue "parentesi graffe" poiché il rientro viene utilizzato per trasmettere significato ai lettori umani e le schede incasinate rendono difficile la lettura del codice.

— James Anderson
fonte