Perché Python pep-8 consiglia vivamente spazi su tab per il rientro?

Vedo su Stack Overflow e PEP 8 che la raccomandazione è di usare spazi solo per il rientro nei programmi Python. Riesco a capire la necessità di un rientro coerente e ho sentito quel dolore.

C'è una ragione di fondo per preferire gli spazi? Avrei pensato che le schede fossero molto più facili da lavorare.

La risposta è stata data proprio lì nel PEP [a cura di: questo passaggio è stato pubblicato nel 2013 ]. Quoto:

Il modo più popolare di rientrare in Python è solo con spazi.

Di quale altra ragione di fondo hai bisogno?

Per dirla in modo meno schietto: considera anche il campo di applicazione del PEP come indicato nel primo paragrafo:

Questo documento fornisce convenzioni di codifica per il codice Python che comprende la libreria standard nella distribuzione principale di Python.

L'intenzione è quella di rendere costantemente formattato tutto il codice che va nella distribuzione ufficiale di Python (spero che possiamo concordare sul fatto che questa è universalmente una buona cosa ™).

Poiché la decisione tra spazi e tab per un singolo programmatore è a) davvero una questione di gusti eb) facilmente gestibile con mezzi tecnici (editor, script di conversione, ecc.), C'è un modo chiaro per terminare tutta la discussione: scegline uno .

Fu Guido a scegliere. Non doveva nemmeno fornire una ragione, ma lo faceva ancora facendo riferimento a dati empirici.

Per tutti gli altri scopi puoi prendere questo PEP come una raccomandazione, oppure puoi ignorarlo: la tua scelta, quella della tua squadra, o i tuoi capi squadra.

Ma se posso darti un consiglio: non mescolarli ;-) [ndr: Mescolare schede e spazi non è più un'opzione.]

Bene, sembra che tutti siano fortemente orientati verso gli spazi. Uso esclusivamente le schede. So benissimo perché.

Le schede sono in realtà una bella invenzione, nata dopo gli spazi. Ti permette di rientrare senza spingere lo spazio milioni di volte o usando una scheda falsa (che produce spazi).

Davvero non capisco perché tutti stiano discriminando l'uso delle schede. È molto simile alle persone anziane che discriminano i giovani per aver scelto una tecnologia più nuova e più efficiente e si lamentano che la composizione a impulsi funziona su tutti i telefoni , non solo su questi nuovi fantasiosi. "La composizione a toni non funziona su tutti i telefoni, ecco perché è sbagliata".

Il tuo editor non è in grado di gestire correttamente le schede? Bene, prendi un editor moderno . Potrebbe essere il momento giusto, siamo nel 21 ° secolo e il tempo in cui un editor era un software complicato ad alta tecnologia è passato da tempo. Ora abbiamo tonnellate e tonnellate di editor tra cui scegliere, tutti quelli che supportano le schede bene. Inoltre, puoi definire quanto dovrebbe essere una scheda, cosa che non puoi fare con gli spazi. Non riesci a vedere le schede? Che cos'è quello per una discussione? Bene, non puoi vedere nemmeno gli spazi!

Posso essere così audace da suggerire di ottenere un editor migliore? Uno di questi ad alta tecnologia, che sono già stati rilasciati circa 10 anni fa, che mostrano personaggi invisibili ? (sarcasmo spento)

L'uso degli spazi provoca molto più lavoro di eliminazione e formattazione. Ecco perché (e tutte le altre persone che lo sanno e sono d'accordo con me) usano le schede per Python.

Mescolare schede e spazi è un no-no e nessun argomento al riguardo. Questo è un casino e non può mai funzionare.

Personalmente non sono d'accordo con gli spazi sulle schede. Per me, le schede sono un carattere / meccanismo di layout del documento mentre gli spazi sono per il contenuto o la delimitazione tra i comandi nel caso del codice.

Devo essere d'accordo con i commenti di Jim sul fatto che le schede non sono davvero il problema, sono le persone e come vogliono mescolare schede e spazi.

Detto questo, mi sono costretto a usare gli spazi per motivi di convenzione. Apprezzo la coerenza rispetto alle preferenze personali.

Il motivo degli spazi è che le schede sono opzionali. Gli spazi sono l'attuale minimo comune denominatore di punteggiatura.

Ogni editor di testo decente ha una "sostituzione di schede con spazi" e molte persone lo usano. Ma non sempre.

Mentre alcuni editor di testo potrebbero sostituire una serie di spazi con una scheda, questo è davvero raro.

Linea di fondo . Non puoi sbagliare con gli spazi. tu potrebbe andare male con le schede. Quindi non utilizzare le schede e ridurre il rischio di errori.

Il problema con le schede è che sono invisibili e le persone non possono mai essere d'accordo sulla larghezza delle schede. Quando mescoli schede e spazi e imposti tabstops su qualcosa di diverso da Python (che utilizza tabstops ogni 8 spazi) vedrai il codice in un layout diverso rispetto a Python. E poiché il layout determina i blocchi, vedrai una logica diversa. Porta a bug sottili.

Se insisti a sfidare PEP 8 e ad usare le tab - o peggio, mescolando tab e spazi - almeno esegui python con l'argomento '-tt', che rende il rientro incoerente (a volte una tab, a volte uno spazio per la stessa rientranza livello) un errore. Inoltre, se possibile, imposta il tuo editor per visualizzare le schede in modo diverso. Ma davvero, l'approccio migliore non è usare le schede, punto.

I problemi principali con il rientro si verificano quando si mescolano schede e spazi. Ovviamente questo non ti dice quale dovresti scegliere, ma è una buona ragione per consigliarne uno, anche se lo prendi lanciando una moneta.

Tuttavia, IMHO ci sono alcuni motivi minori per favorire gli spazi rispetto alle schede:

• Strumenti diversi. A volte il codice viene visualizzato al di fuori dell'editor di un programmatore. Per esempio. pubblicato in un newsgroup o forum. Gli spazi in genere funzionano meglio delle schede qui: ovunque gli spazi si alterano, anche le schede lo fanno, ma non viceversa.

• I programmatori vedono la fonte in modo diverso. Questo è profondamente soggettivo - è il principale vantaggio delle schede o un motivo per evitarle a seconda di quale parte stai. Tra i lati positivi, gli sviluppatori possono visualizzare la sorgente con il rientro preferito, quindi uno sviluppatore che preferisce il rientro a 2 spazi può lavorare con uno sviluppatore a 8 spazi sulla stessa fonte e comunque vederlo come preferisce. Il rovescio della medaglia è che ci sono ripercussioni su questo - ad alcune persone piace l'8-spazio perché fornisce un feedback molto visibile sul fatto che sono nidificati troppo profondamente - possono vedere il codice controllato dall'intrentatore che si avvolge costantemente nel loro editor. Il fatto che ogni sviluppatore veda il codice nello stesso modo porta a una maggiore coerenza rispetto alle lunghezze delle linee e anche ad altre questioni.

• Rientro della linea continua. A volte si desidera rientrare in una riga per indicare che è presente nella precedente. per esempio.

  def foo():
      x = some_function_with_lots_of_args(foo, bar, baz,
                                          xyzzy, blah)

  Se si usano le schede, non c'è modo di allinearlo per le persone che usano diversi tabstops nel loro editor senza mescolare spazi e schede. Questo uccide efficacemente il vantaggio di cui sopra.

Ovviamente, però, si tratta di una questione profondamente religiosa, di cui è afflitta la programmazione. Il problema più importante è che dovremmo sceglierne uno, anche se non è quello che preferisci. A volte penso che il più grande vantaggio del rientro significativo sia che almeno ci risparmiamo il posizionamento delle parentesi di fiamma.

Vale anche la pena leggere questo articolo di Jamie Zawinski sull'argomento.

Si noti che l'uso delle schede confonde un altro aspetto di PEP 8:

Limitare tutte le righe a un massimo di 79 caratteri.

Diciamo, ipoteticamente, che usi una larghezza di tabulazione di 2 e io uso una larghezza di tab di 8. Scrivi tutto il tuo codice in modo che le tue righe più lunghe raggiungano 79 caratteri, quindi inizio a lavorare sul tuo file. Ora ho un codice difficile da leggere perché (come afferma il PEP):

Il wrapping predefinito nella maggior parte degli strumenti interrompe la struttura visiva del codice

Se usiamo tutti 4 spazi, è SEMPRE lo stesso. Chiunque il cui editor può supportare una larghezza di 80 caratteri può leggere comodamente il codice. Nota: il limite di 80 caratteri è una guerra santa in sé e per sé, quindi non cominciamo qui.

Qualsiasi editor non sucky dovrebbe avere un'opzione per usare gli spazi come se fossero schede (sia di inserimento che di cancellazione), quindi non dovrebbe essere un argomento valido.

La risposta alla domanda è: PEP-8 vuole fare una raccomandazione e ha deciso che, poiché gli spazi sono più popolari, raccomanderà fortemente gli spazi rispetto alle schede.

Note su PEP-8

PEP-8 dice "Usa 4 spazi per livello di rientro".
È chiaro che questa è la raccomandazione standard.

"Per il codice davvero vecchio che non vuoi rovinare, puoi continuare a usare le schede a 8 spazi."
È chiaro che ci sono ALCUNE circostanze in cui è possibile utilizzare le schede.

"Non mescolare mai schede e spazi."
Questo è un chiaro divieto di mescolare - penso che siamo tutti d'accordo su questo. Python può rilevare questo e spesso soffoca. L'uso dell'argomento -tt rende questo un errore esplicito.

'Il modo più popolare di rientrare in Python è solo con spazi. Il secondo modo più popolare è solo con le schede ".
Questo afferma chiaramente che entrambi sono usati. Solo per essere ultra-chiari: non dovresti mai mescolare spazi e tab nello stesso file.

"Per i nuovi progetti, si consiglia vivamente di utilizzare solo spazi rispetto alle schede."
Questa è una chiara raccomandazione e forte, ma non un divieto di schede.

Non riesco a trovare una buona risposta alla mia domanda in PEP-8. Uso le schede, che ho usato storicamente in altre lingue. Python accetta i sorgenti con l'uso esclusivo delle schede. È abbastanza buono per me.

Ho pensato di provare a lavorare con gli spazi. Nel mio editor, ho configurato un tipo di file per utilizzare gli spazi esclusivamente e quindi inserisco 4 spazi se premo tab. Se premo tab troppe volte, devo cancellare gli spazi! Arrgh! Elimina quattro volte di più delle schede! Il mio editor non può dire che sto usando 4 spazi per i rientri (anche se un editor AN potrebbe essere in grado di farlo) e ovviamente insiste sull'eliminazione degli spazi uno alla volta.

Non si potrebbe dire a Python di considerare le tab come n spazi quando si leggono le rientranze? Se potessimo concordare 4 spazi per rientro e 4 spazi per tab e consentire a Python di accettarlo, allora non ci sarebbero problemi.
Dovremmo trovare soluzioni vantaggiose per tutti.

Ho sempre usato le schede nel mio codice. Detto questo, di recente ho trovato un motivo per utilizzare gli spazi: durante lo sviluppo sul mio tablet Internet Nokia N900, ora avevo una tastiera senza un tasto Tab. Questo mi ha costretto a copiare e incollare le schede o a riscrivere il mio codice con spazi. Ho riscontrato lo stesso problema con altri telefoni. Certo, questo non è un uso standard di Python, ma qualcosa da tenere a mente.

JWZ lo dice meglio :

Quando [le persone] leggono il codice e quando hanno finito di scrivere un nuovo codice, si preoccupano di quante colonne dello schermo con cui il codice tende a rientrare quando si apre un nuovo ambito (o sexpr, o altro) ...

... La mia opinione è che il modo migliore per risolvere i problemi tecnici è imporre che il carattere TAB ASCII # 9 non appaia mai nei file su disco: programma il tuo editor per espandere i TAB su un numero appropriato di spazi prima di scrivere le righe sul disco. ..

... Questo presuppone che non usi mai le schede in punti in cui sono effettivamente significative, come nelle costanti di stringhe o caratteri, ma non lo faccio mai: quando importa che sia una scheda, uso sempre "\ t" invece.

Poiché python si basa sul rientro per riconoscere la struttura del programma, è necessario un modo chiaro per identificare l'identificazione. Questo è il motivo per scegliere spazi o schede.

Tuttavia, Python ha anche una forte filosofia di avere un solo modo di fare le cose, quindi dovrebbe esserci una raccomandazione ufficiale per un modo di fare rientro.

Sia gli spazi che le schede rappresentano sfide uniche per un editor da gestire come rientro. La gestione delle schede stesse non è uniforme tra gli editor o le impostazioni dell'utente. Poiché gli spazi non sono configurabili, rappresentano la scelta più logica in quanto garantiscono che il risultato sia uguale ovunque.

Il vantaggio più significativo che posso dire degli spazi rispetto alle schede è che molti programmatori e progetti usano un determinato numero di colonne per il codice sorgente e se qualcuno commette una modifica con il suo tabstop impostato su 2 spazi e il progetto utilizza 4 spazi come il tabstop delle righe lunghe sarà troppo lungo per la finestra dell'editor di altre persone. Concordo sul fatto che le schede sono più facili da lavorare, ma penso che gli spazi siano più facili per la collaborazione, il che è importante in un grande progetto open source come Python.

Puoi avere la tua torta e mangiarla. Imposta il tuo editor per espandere automaticamente le schede negli spazi.

(Sarebbe :set expandtabin Vim.)

La mia ipotesi è che la maggior parte degli editor di testo di Linux fanno apparire le impostazioni predefinite ridicolmente grandi per impostazione predefinita. Non riesco a pensare a nessun altro buon motivo per usare gli spazi sulle schede.

Oltre a tutti gli altri motivi già citati (coerenza, mai mescolare spazi, tab ecc.) Credo che ci siano alcuni altri motivi per cui la convenzione sui 4 spazi deve essere annotata. Questi si applicano solo a Python (e forse ad altre lingue in cui il rientro ha un significato). Le schede possono essere più belle in altre lingue, a seconda delle preferenze individuali.

1. Se un editor non mostra le schede (cosa che accade, a seconda della configurazione, in parecchi), un altro autore potrebbe presumere che il tuo codice usi 4 spazi, b / c quasi tutto il codice Python che è disponibile pubblicamente; se lo stesso editor avesse una larghezza di tabulazione di 4, potrebbero accadere cose brutte - almeno, quella povera persona perderà tempo per un problema di rientro che sarebbe stato molto facile evitare attenendosi alla convenzione. Quindi, per me, il motivo numero uno è evitare i bug con coerenza.

2. Riformulando la questione di quale sia meglio, schede o spazi, ci si dovrebbe chiedere quali siano i vantaggi delle schede; Ho visto molti post elogiare le schede, ma pochi argomenti convincenti per loro; buoni editor come emacs, vi (m), kate, ... fanno il rientro corretto in base alla semantica del tuo codice - anche senza schede; gli stessi editor possono essere facilmente configurati per non rientrare nel backspace ecc.

3. Alcune persone hanno preferenze molto forti quando si tratta della loro libertà nel decidere l'aspetto / il layout del codice; altri apprezzano la coerenza rispetto a questa libertà. Python riduce drasticamente questa libertà dettando che il rientro viene usato per blocchi ecc. Questo può essere visto come un bug o una funzionalità, ma in qualche modo viene fornito con la scelta di Python. Personalmente, mi piace questa coerenza: quando inizi a scrivere un codice su un nuovo progetto, almeno il layout è vicino a quello a cui sono abituato, quindi è abbastanza facile da leggere. Quasi sempre.

4. L'uso di spazi per il rientro consente "trucchi di layout" che possono facilitare la comprensione del codice; alcuni esempi sono elencati in PEP8; per esempio.

   foo = long_function_name(var_one, var_two,
                            var_three, var_four)
   
   # the same for lists
   a_long_list = [1,
                  2,
                  # ...
                  79]
   
   # or dictionaries
   a_dict = {"a_key": "a_value",
             "another_key": "another_value"}

   Naturalmente, anche quanto sopra può essere scritto bene

   foo = long_function_name(
       var_one, var_two,
       var_three, var_four)
   
   # the same for lists
   a_long_list = [
       1,
       2,
       # ...
       79]
   
   # or dictionaries
   a_dict = {
       "a_key": "a_value",
       "another_key": "another_value"}

   Tuttavia, quest'ultimo richiede più righe di codice e talvolta si ritiene che meno righe siano migliori (b / c si ottiene di più su una singola schermata). Ma se ti piace l'allineamento, gli spazi (preferibilmente assistiti da un buon editor) ti danno, in un certo senso, più libertà in Python rispetto alle schede. [Beh, immagino che alcuni editor ti permettano di fare lo stesso w / tab;) - ma con spazi, tutti fanno ...]

5. Tornando allo stesso argomento di tutti gli altri - PEP 8 detta (ok, raccomanda vivamente) gli spazi. Se stai arrivando a un progetto che utilizza solo schede, ovviamente, hai poca scelta. Ma a causa dell'istituzione delle convenzioni PEP 8, quasi tutti i programmatori Python sono abituati a questo stile. Questo rende molto più facile trovare un consenso su uno stile che è accettato dalla maggior parte dei programmatori ... e avere persone d'accordo sullo stile potrebbe essere molto difficile altrimenti.

6. Gli strumenti che aiutano a rafforzare lo stile sono generalmente consapevoli di PEP 8 senza ulteriore sforzo. Questo non è un grande motivo, ma è bello avere cose funzionanti ~ fuori dalla scatola.

Il problema universale con le schede è che possono essere rappresentate in modo diverso in ambienti diversi.
In un determinato editor, una scheda potrebbe essere 8 spazi o potrebbe essere 2.
In alcuni editor, puoi controllarlo, mentre in altri no.

Un altro problema con le schede è il modo in cui sono rappresentate nell'output stampato. Credo che la maggior parte delle stampanti interpreti una scheda come 8 spazi.

Con gli spazi, non c'è dubbio. Tutto andrà come previsto dall'autore.

Sulla discussione tra Jim e Thomas Wouters nei commenti.

Il problema era ... dato che la larghezza delle schede e degli spazi può variare - e poiché i programmatori non possono concordare su nessuna delle due larghezze - perché le schede hanno la colpa.

Sono d'accordo con Jim su questo: le schede NON sono malvagie in sé e per sé. Ma c'è un problema...

Con gli spazi posso controllare come "IL MIO CODICE PROPRIO" aspetto di in OGNI editor del mondo. Se uso 4 spazi, quindi indipendentemente dall'editor in cui apro il mio codice, avrà la stessa distanza dal margine sinistro. Con le schede sono in balia dell'impostazione della larghezza della scheda per l'editor - anche per IL MIO CODICE. E non mi piace.

Quindi, mentre è vero che anche gli spazi non possono garantire coerenza - almeno ti offrono un maggiore controllo sull'aspetto del tuo codice OWN ovunque - qualcosa che le schede non possono.

Penso che NON sia la coerenza nei programmatori che scrivono il codice - ma la coerenza negli editor che mostrano quel codice - che gli spazi rendono più facile da raggiungere (e imporre).