Schede e spazi nella programmazione Python

https://stackoverflow.com/questions/119562

02-07-2019
|

Domanda

Ho sempre usato le schede per il rientro quando eseguo la programmazione Python. Ma poi mi sono imbattuto in una domanda qui su SO in cui qualcuno ha sottolineato che la maggior parte dei programmatori Python usano spazi anziché tab per minimizzare gli errori da editor a editor.

In che modo fa la differenza? Ci sono altri motivi per cui si dovrebbero usare gli spazi anziché le schede per Python? O semplicemente non è vero?

Devo cambiare il mio editor per inserire subito spazi anziché tabulazioni o continuare come prima?

Soluzione

Perché PEP-8 ci dice di usa gli spazi.

Altri suggerimenti

Stanco di inseguire errori di battitura per i rientri (8 spazi? no, 7 oops 9 ...) Ho cambiato le mie fonti in "solo schede".

1 scheda == 1 trattino, punto e blocco

Il punto è: se si desidera visualizzare il rientro con una larghezza di 4, 8 o pi / 12 caratteri, basta modificare le impostazioni nell'editor di testo, non scherzare con il codice.

(Personalmente, io uso la scheda di larghezza 4 caratteri ... ma alcuni preferirebbero 3 o 8 spazi, o addirittura usare caratteri a larghezza variabile.)

Così parlava il Signore: ti indenterai con quattro spazi. Ne più ne meno. Quattro sarà il numero di spazi che indenterai e il numero del tuo rientro sarà quattro. Otto non indenterai, né indenterai né due, tranne che poi procederai a quattro. Le schede sono subito disponibili. - Georg Brandl

UTILIZZARE UN EDITOR CHE VISUALIZZA I PERSONAGGI DELLA TAB (tutti gli spazi, per quella materia). Stai programmando, non scrivendo un articolo.

Uso le schede. Non c'è spazio per un errore di uno spazio nelle schede (se riesci a vederli). Il problema è che le persone usano editor diversi e l'unica cosa comune al mondo è: tab == indent, come sopra. Qualcuno arriva con il tasto tab impostato sul numero errato di spazi o lo fa manualmente e fa casino. TAB e usa un vero editor. (Questo non è solo contrario al PEP, riguarda anche C / C ++ e altri linguaggi agnostici per gli spazi bianchi).

/ esce dalla soapbox

Il motivo principale per cui ho usato le schede sugli spazi è il tasto backspace. Se sono su una linea e voglio backspace-rimuovere un rientro solo su quella riga, devo colpire backspace 4x se fossero spazi; invece, devo solo colpirlo una volta se è una scheda.

Continuerò a utilizzare le schede perché & # 8212; come è stato affermato prima di & # 8212; è più facile convertire da schede in spazi, ma non viceversa.

Sto pensando di voler scrivere un semplice programma che converta il codice con gli spazi in codice con le schede, perché io odio gli spazi. Mi portano sul muro!

Oh! E usare i tasti freccia per navigare a sinistra ea destra è sempre un dolore nel culo quando sono gli spazi.

AGGIORNAMENTO: Sublime Text 3 ora elimina una scheda soft completa con il tasto backspace; tuttavia, la navigazione con i tasti freccia è ancora noiosa.

AGGIORNAMENTO: ora uso vscode e ho anche scritto un estensione TabSanity per risolvere backspace, eliminare e navigare con i tasti freccia.

Il più " pythonic " il modo è utilizzare 4 spazi per livello di rientro. L'interprete Python riconoscerà comunque spazi o tabulazioni. L'unico gottcha è che non devi mai mescolare spazi e tabulazioni , scegli uno o l'altro. Detto questo, le specifiche raccomandano gli spazi, la maggior parte degli sviluppatori usa gli spazi, quindi a meno che tu non abbia una buona ragione per non farlo, direi di andare con gli spazi.

Per quanto ne so, ecco i pro e i contro di tabulazioni vs spazi.

Pro delle schede:

Sono necessari meno tasti per indentare, indentare e attraversare il rientro. (Anche se il tuo IDE ha una certa intelligenza di indentazione dello spazio, non sarà mai buono come le schede.)
Diversi programmatori possono utilizzare diverse dimensioni di visualizzazione delle schede come desiderano.
Non puoi mai avere il cursore " dentro " un carattere di rientro. Ad esempio, supponiamo che stai copiando alcune righe, con le schede puoi fare clic vagamente vicino all'inizio di una riga per iniziare la selezione e otterrai tutta la prima scheda. Con gli spazi è probabile che ti perda il primo personaggio spaziale a meno che non colpisca il piccolo bersaglio tra esso e il margine. Analogamente per rimuovere un rientro da una linea, la maggior parte degli editor non gestisce bene la pressione del backspace se il cursore si trova nel mezzo di un carattere di rientro a quattro spazi. Solitamente rimuoverà uno spazio. Con le schede funziona come previsto.
Coerenza con altre lingue, quindi non è necessario impostare l'editor per l'uso, ad es. schede per C ++ / Java e spazi per Python.
I rientri errati possono essere più evidenti (ovvero una scheda aggiuntiva è molto più grande di uno spazio extra).

Contro di schede:

La maggior parte dei programmatori Python usa gli spazi in modo da andare contro la convenzione.
L'uso degli spazi per allineare le istruzioni multilinea è più semplice dell'uso delle schede. potresti usare le tab per il rientro, gli spazi per l'allineamento, ma sembra un po 'rischioso in Python!

Ci sono alcuni non-problemi che sono esagerati da alcune persone:

Potresti ottenere spazi randagi nella rientranza a schede che rovina le cose: praticamente tutti gli IDE / editor supportano la visualizzazione di spazi bianchi, ed è quasi altrettanto probabile che tu abbia schede vaganti nelle rientranze dello spazio! Non riesco comunque a vedere questo essere un errore comune. Inoltre, maggior parte degli errori di rientro saranno rilevati da Python e buoni IDE dovrebbero essere in grado di evidenziare diversi rientri.
Non puoi allineare facilmente le cose con le schede: questo è vero se stai cercando un allineamento perfetto per i caratteri, ma PEP-8 lo consiglia contro questo, e Python non gioca bene con le dichiarazioni multilinea in ogni caso.
Le persone hanno impostazioni di differenza per le dimensioni di visualizzazione delle schede nei loro editor, quindi il tuo codice apparirà diverso in luoghi diversi: Sì, questa è in realtà una caratteristica utile delle schede.

Ho iniziato a utilizzare gli spazi per essere coerenti con altri codici Python, ma ad essere sinceri è abbastanza frustrante che probabilmente tornerò alle schede. Molto dipende dalle capacità del tuo IDE, ma nella mia esperienza nessuna quantità di supporto IDE per il rientro dello spazio è buona come usare semplicemente le schede.

Quindi, a meno che davvero non ti piaccia essere in contrasto con most (presumibilmente non tutti!) Codice Python, usa le schede e attiva la visualizzazione degli spazi bianchi e l'evidenziazione del rientro (se a disposizione). Il motivo principale per me è la facilità di selezione e la riduzione (abbastanza significativa dell'IMO) delle sequenze di tasti. Alcune convenzioni sono stupide.

Aggiornamento : ho scoperto che esiste un editor in tutto il mondo (escluse le sciocchezze come Vim) che supporta correttamente gli spazi come rientro: Atom. Ha un'opzione chiamata & Quot; atomic tabstops & Quot; che fa si che 4 spazi si comportino come se fossero una scheda a tutti gli effetti (tranne che per essere in grado di ridimensionarla). Purtroppo Atom è un editor piuttosto lento e gonfio, ma questa è una grande funzionalità e se sei costretto a usare gli spazi potrebbe essere una buona opzione. Spero che un giorno altri editor inizieranno a supportarlo. Ecco il problema per VSCode .

Di recente mi sono imbattuto in un articolo intitolato Python: Myths about Indentation che discute di questo e delle relative domande. L'articolo ha buone ragioni per raccomandare l'uso degli spazi quando si scrive il codice Python, ma c'è sicuramente spazio per il disaccordo.

Credo sia vero che la maggior parte dei programmatori Python usano solo spazi.

Utilizzare un editor che consente di inserire spazi fino al tabstop quando si preme il tasto TAB, anziché inserire un carattere \ t. E poi dimenticalo.

PUOI mescolare schede e spazi ... MA una scheda è considerata come la stessa rientranza di 8 spazi, quindi a meno che il tuo editor non sia impostato per considerare una scheda come 8 spazi stai chiedendo problemi quando li mescoli .

L'unico inconveniente che riscontro nell'utilizzo degli spazi anziché delle schede è che non è possibile rimuovere facilmente un livello di rientro; devi rimuovere quattro spazi invece di una sola scheda.

Regola schede. Stesso argomento per i cicli nidificati e si desidera portare il ciclo esterno & Quot; back & Quot; 1 livello. Suggerimento: se desideri convertire il vecchio codice Python crivellato di spazi in schede, utilizza l'utilità TabOut disponibile come eseguibile su http://www.textpad.com/add-ons/ .

Sento fortemente che qualunque sia la convenzione storica, le schede sono semplicemente una scelta migliore e dovrebbero sostituire gli spazi in ogni futura riga del codice Python scritto. Come cacciare un tiranno incompetente. La mia logica per questo è: semplicità come valore fondamentale . Usa due o forse quattro personaggi per il compito semantico di uno? Non c'è giustificazione oltre la tradizione, IMO.

L'errore da editor a editor si verifica quando si ha rientro misto in un file . Ciò si presenta come segue: un blocco di codice viene indentato con 4 spazi, quindi un livello di rientro & Quot; in & Quot; viene indentato con le schede. Ora il pagano che lo ha fatto (mescolando tab e spazi) lo ha fatto, quindi anche i suoi tab sono 4 spazi, quindi non vede problemi e Python non vede problemi.

Ora la nostra vittima arriva più tardi e ha le sue schede impostate su 8 spazi. Ora le nostre vittime pensano che il codice sembri tutto sbalzato e lo risolve rimuovendo rimuovendo un livello di rientro , che ora fa apparire il codice come è ancora 2 livelli di rientro, ma è veramente un livello . A questo punto si scatena l'inferno.

La lezione qui è che non dovresti mai, mai, mescolare schede e spazi. Se continui a questo, allora è facile reindirizzare il tuo codice in spazi o schede, indipendentemente da quale usi personalmente. Il modo migliore per assicurarti di non mescolare schede e spazi è eseguire sempre python con -tt, che produrrà un errore quando si mescolano schede e spazi.

Per quanto riguarda le schede e gli spazi, io personalmente uso le schede in modo che il rientro sia separato dall'aspetto: è molto più semplice cambiare l'aspetto del codice quando è rientrato con le schede piuttosto che con gli spazi. So che questo è contrario a quello del 99% dei programmatori Python, ma questa è la mia preferenza personale , ed è comunque facile convertire un file a schede in uno spaziato. Il contrario non è sempre vero, dal momento che puoi cancellare accidentalmente 4 spazi nelle stringhe, ecc.

Quando appresi Python per la prima volta, rimasi un po 'scoraggiato dall'idea di uno spazio bianco significativo, poiché la maggior parte delle lingue per usarlo sono poco flessibili. Detto questo, sono rimasto impressionato dalla capacità di Python di comprendere una varietà di stili di rientro. Quando si considera quale stile utilizzare per un nuovo progetto, penso che sia importante tenere a mente due cose.

Innanzitutto, è importante capire come Python interpreta il rientro. Bryan Oakley ha menzionato la possibilità di errori off-by-one quando si usano le schede, ma questo in realtà non è possibile con le impostazioni predefinite dell'interprete. C'è una spiegazione migliore di ciò in Learning Python , da O'Reilly media .

Fondamentalmente, esiste una variabile (che può essere modificata includendo un commento nella parte superiore di un file sorgente # tab-width:) che definisce la larghezza della scheda. Quando Python incontra una scheda, aumenta la distanza di rientro al multiplo successivo della larghezza della scheda . Pertanto, se uno spazio seguito da una scheda viene immesso lungo la sinistra del file, il multiplo successivo della larghezza della scheda è 8. Se viene inserita una scheda da sola, accade la stessa cosa.

In questo modo, è sicuro, se l'editor è configurato correttamente, usare le schede e persino mescolare schede e spazi. Fintanto che imposti la tab del tuo editor si ferma alla stessa larghezza della dichiarazione della larghezza della tab di Python (o 8 se è assente). È generalmente una cattiva idea usare un editor con una larghezza di tabulazione diversa da 8 spazi, a meno che non specifichi la larghezza di tabulazione nel file.

In secondo luogo, gran parte della progettazione sintattica di Python è di incoraggiare la leggibilità del codice e lo stile coerente tra i programmatori dello stesso progetto. Detto questo, la domanda diventa, per ogni particolare progetto, cosa renderà il codice il più leggibile dalle persone che lavorano al progetto . Certamente è una buona idea mantenere uno stile di rientro coerente, ma a seconda della piattaforma e dell'editor utilizzati dal progetto, uno stile diverso può avere senso per diversi progetti. Se non vi sono motivi validi per non conformarsi a PEP & Nbsp; 8 , quindi ha senso farlo, perché sarà conforme a ciò che le persone si aspettano.

Ho riscontrato progetti che utilizzano correttamente un mix di schede e spazi. Fondamentalmente gli spazi vengono utilizzati per indentare piccole sezioni, dove il fatto che si trova in una sezione rientrata è relativamente poco importante; mentre le schede vengono utilizzate per attirare l'attenzione del lettore su una grande caratteristica strutturale. Ad esempio, le classi iniziano con una scheda, in cui i semplici controlli condizionali all'interno di una funzione utilizzano due spazi.

Le schede sono utili anche quando si hanno a che fare con grandi blocchi di testo rientrati su più livelli. Quando si esce da 3-4 livelli di rientro, è molto più facile allinearsi con la scheda appropriata piuttosto che allinearsi con il numero corretto di spazi. Se un progetto non utilizza lo stile consigliato PEP & Nbsp; 8, è probabilmente meglio scrivere una guida di stile in un file da qualche parte in modo che il modello di rientro rimanga coerente e altre persone possano leggere esplicitamente come configurare il proprio editor per partita.

Inoltre, Python 2.x ha un'opzione -t per emettere avvisi su schede e spazi misti e -tt per emettere un errore. Ciò si applicava solo a schede e spazi misti all'interno dello stesso ambito. Python & Nbsp; 3 assume <=> e per quanto ne ho trovato, non c'è modo di disabilitare quel controllo.

Sono principalmente un programmatore C ++, ma a volte i miei progetti includono piccole quantità di Python. Uso le schede per indentare il mio codice C ++. Ciò significa che qui ho tre opzioni:

Usa le schede in C ++ e gli spazi in Python. Ciò consente ai miei file C ++ di rimanere come sono e seguo la raccomandazione PEP-8, ma non sono coerente con il mio progetto.
Cambia il mio codice C ++ per usare gli spazi. Ciò consente a tutti i miei file all'interno del mio progetto di essere coerenti e seguo la raccomandazione PEP-8, ma mi richiede di tornare indietro e modificare tutti i miei file C ++. Lo considero negativo perché preferisco le schede.
Usa le schede nel mio codice C ++ e codice Python. Ciò rende coerente il mio intero progetto e mi consente di utilizzare il mio stile di rientro preferito: le schede. Il rovescio della medaglia è che non sto seguendo lo standard PEP-8.

Per i miei progetti, generalmente vado con l'opzione 3.

L'esperienza e PEP-8 concludono entrambi chiaramente che la miscelazione spazi e TAB s devono essere evitati. Se vuoi mescolarli devi visualizzare gli spazi bianchi nell'IDE - ma poi perdi il vantaggio dell'indentazione di Python rendendo facilmente visibili gli ambiti. La visualizzazione di spazi bianchi in un IDE ingombra il display.

Se si tratta di TAB o spazi, allora devono essere spazi per un semplice motivo: si può cambiare quasi tutti gli IDE e gli editor di testo per sostituire automaticamente le schede con spazi, ma non è vero il contrario.

Anche se ci sono IDE che possono convertire automaticamente spazi iniziali in una linea in tabulazioni, questo alla fine porterà ad avere una combinazione di tabulazioni e spazi. Prendi in considerazione istruzioni a più righe come chiamate di funzione con molti parametri o stringhe di documenti. Mentre & Quot; ascii-art & Quot; va anche evitato che può succedere facilmente per caso che un singolo spazio venga lasciato dopo le schede iniziali.

Altre risposte hanno portato diversi argomenti a favore delle schede:

Colpire <=> è più efficiente. Ovviamente questo è vero, ma tutti gli editor di testo consentono di inserire immediatamente il numero desiderato di spazi quando viene premuto un tasto tab
Rientro / Dedentazione è più semplice quando si deve solo rimuovere una scheda invece di 2/3/4/8 spazi. Vero, ma la maggior parte degli editor di testo consente di farlo automaticamente in ogni caso: la selezione a blocchi, il rientro / il rientro sono funzionalità di base di un editor di programmazione, come commenti / commenti. Se un editor di testo non ha implementato questo, dovrebbe almeno avere una funzionalità macro facile da usare con la quale si può ottenere la stessa cosa.
Programmatori diversi come larghezze di rientro diverse. Questo è vero e un chiaro vantaggio di usare solo <=> s. Il problema è l'interazione con altri individui e / o team. Perché questo funzioni nel mondo reale, tutti dovrebbero essere d'accordo sul fatto di usare solo <=> s. Dal momento che ciò non è avvenuto, non funziona comunque. In uno scenario del mondo reale c'è una serie di linee guida per la codifica su cui un progetto concorda comunque, e il metodo di rientro è sicuramente uno di questi - anche in altri linguaggi di programmazione in cui le implicazioni sono & Quot; solo & Quot; a livello visivo.

Imho, il punto principale che manca la maggior parte (se non tutte) delle risposte qui è l'interazione tra team o individui, specialmente in scenari in cui l'elenco dei partecipanti non è noto all'inizio. Quando il codice incontra il codice o tutti devono usare le schede o tutti devono usare gli spazi. Non può essere miscelato senza eventualmente incorrere in problemi di funzionalità. Le persone non sono perfette. Gli strumenti non sono perfetti. Ecco perché non dovremmo usare <=> s affatto

Nessuna risposta è completa senza il link che Greg ha fornito nella sua risposta già: Python: miti sull'indentazione

Ognuno ha preferenze diverse su quanto codice deve essere indentato. Supponiamo che tu condividi il codice con qualcuno e che abbia preferenze diverse in merito al rientro. Se i rientri sono nelle schede, il tuo amico può sempre semplicemente modificare la larghezza della scheda nelle impostazioni dell'editor. Tuttavia, se i rientri sono negli spazi, il tuo amico dovrà effettivamente cambiare il codice sorgente se desidera impostarlo secondo le proprie preferenze. Quindi quando ricevi le modifiche del tuo amico, puoi decidere di riportarlo alle tue preferenze. In questo caso, dovrai affrontare il tedio di cambiare i livelli di rientro avanti e indietro, oppure una persona deve adottare le preferenze dell'altra a livello di rientro. Se sia tu che il tuo amico utilizzate le schede, il fatto che abbiate preferenze diverse non è un problema, poiché potete vedere livelli di rientro diversi mentre il codice rimane invariato. Ecco perché, secondo me, le schede sono migliori degli spazi per il rientro in tutti i linguaggi di programmazione.

C'è uno scenario in cui le schede semplicemente non funzionano, vale a dire: a seconda dello stile di codifica che stai utilizzando, potresti dover rientrare alcune righe di codice con una precisione di uno spazio, ovvero:

def foobar():
    x = some_call(arg1,
                  arg2)

In tal caso, l'utilizzo di schede puramente non funzionerà affatto; l'uso delle schede per il rientro principale e gli spazi per il sottotrattino funzioneranno ma violeranno la dura regola di non mescolare i due.

Questo non sarà il caso tuttavia quando si utilizza un documento di stile / convenzioni di codifica che evita situazioni come nell'esempio di codice precedente.

Il problema con l'utilizzo degli spazi anziché delle schede è che la dimensione del file diventa così incredibilmente grande ... Ad esempio, un 500 & nbsp; il file con rientro spaziale KB potrebbe essere ridotto a 200 & nbsp; KB durante lo scambio spazi per le schede, motivo per cui utilizzo sempre le schede.

Dimensioni file ridotte significano caricamento, compilazione, esecuzione (in alcuni casi) più rapidi, ecc.

Per me, non ha senso usare gli spazi, ma se qualcuno usa un editor che ha problemi con le schede, allora può sostituire " \ t " con " & Quot; o " & Quot; o qualunque cosa ...

Oltre a tutti gli argomenti già elencati, trovo questo abbastanza importante (da Miti sull'indentazione ):

Inoltre, le schede vengono spesso distrutte o erroneamente convertite durante le operazioni di copia & amp; incolla o quando un pezzo di codice sorgente viene inserito in una pagina Web o in un altro tipo di codice di markup.

Un altro argomento (fortemente specifico per l'ambiente, tuttavia) contro le schede è che sono a volte mancanti sulle tastiere del telefono . Questo potrebbe probabilmente essere risolto installando una tastiera alternativa, ove possibile.

Un argomento per schede che nessuno sembrava aver ancora menzionato è che 1 scheda è 1 carattere (0x09, 1 byte nel file), mentre 4 spazi sono 4 caratteri (4 volte 0x20, 4 byte nel file); pertanto, l'utilizzo degli spazi si traduce in uno spreco di spazio 4x.

Per concludere questo elenco incoerente di argomenti, vorrei citare la risposta di Tim Peters nella Numero 7012: Schede è meglio degli spazi per il rientro :

Il Python " solo spazi " lo standard è per codice distribuito. Anni di esperienza precoce ci hanno insegnato oltre ogni dubbio le schede hanno causato infiniti problemi per il codice condiviso (...)

In che modo fa la differenza?

Alcuni editor sono configurati per impostazione predefinita per sostituire un singolo carattere di tabulazione con un numero fisso di caratteri di spazio, ma altri no. Se tutti usano spazi, questa differenza nelle impostazioni dell'editor predefinite può essere ignorata.

Ci sono altri motivi per cui si dovrebbero usare gli spazi anziché le schede per Python? O semplicemente non è vero?

Sì, ci sono altri motivi validi, come sottolineato da molte risposte prima di me. & Quot; PEP-8 quot &; dice così, tuttavia, NON è uno di quei motivi. Questo deriva dal mito perpetuante che PEP-8 è lo standard di codifica per tutto codice Python, quando in realtà è solo lo standard di codifica per l'insieme standard di librerie Python. Alcuni sostengono che PEP-8 è ampiamente accettato e alcuni sostengono che la maggior parte dei programmatori Python utilizzano spazi anziché tab. Vorrei chiedere prove di queste affermazioni, poiché il numero di voti su questo sito mostra CHIARAMENTE che le schede sono preferite dalle masse. Trovo piuttosto spiacevole che tu abbia accettato & Quot; PEP8 lo dice & Quot; come risposta alla tua domanda, quando in realtà ci sono molte altre risposte che spiegano effettivamente i vantaggi e gli svantaggi relativi di spazi e schede.

Devo cambiare il mio editor per inserire subito spazi anziché tabulazioni o continuare come prima?

Dipende, e la risposta a questa domanda finale è dove pensavo di poter aggiungere un po 'di valore a questo thread. IMHO, indipendentemente dalla lingua utilizzata, il miglior standard di codifica da utilizzare dipende dalla situazione in cui ti trovi:

Se hai iniziato a lavorare su una base di codice già esistente: non essere difficile, segui lo standard di codifica esistente
Se una squadra sta iniziando un nuovo progetto da zero: discuti, decidi su uno standard di codifica all'inizio come squadra, e segui
Se vai da solo: fai tutto ciò che ti fa sentire il più felice e il più produttivo

Quindi in quale situazione ti trovi?

Infine, per chiarire la mia posizione, per i miei progetti da solista, uso le schede perché le schede hanno più senso per me e sono più produttivo con le schede.

Credo che ci sia una soluzione per avere entrambi:

Compatibilità con PEP-8 e utilizzo degli spazi
Convenienza dell'uso della scheda anziché di 4 spazi

In Notepad ++, vai su " preferenze " - > " impostazioni della scheda " e scegli " Python " dall'elenco a destra. Quindi assicurati che & Quot; dimensione scheda: 4 & Quot ;, e seleziona la casella & Quot; sostituisci [tab] con spazio & Quot ;. In questo caso, puoi semplicemente usare il tasto tab per rientrare, ma Notepad ++ lo trasforma in 4 spazi per te.

Questo è PEP & nbsp; 8 da luglio 2017:

Sembra che questa affermazione non lasci spazio a nessun'altra scelta.

Ma questo non è solo ciò che PEP & nbsp; 8 ci dice, poche righe dopo:

In quanto sopra, la prima istruzione esprime una preferenza per gli spazi, e la seconda istruzione riconosce l'esistenza di codice rientrato con le schede e questa preferenza per alcuni programmatori.

Quindi : PEP & nbsp; 8 è tollerante al rientro delle schede. Non tollera tabulazione e spazio mescolati per il rientro, il che, poiché il rientro stesso è obbligatorio, è comprensibile.

Vale la pena ricordare che lo stile di codifica Python di Google segue anche Regola di 4 spazi.

Esistono altri vari argomenti e giustificazioni a favore di schede o di 4 spazi.

Se lavori in un'azienda che impone PEP & nbsp; 8 o condividi regolarmente il tuo codice con altri che seguono PEP & nbsp; 8, il buon senso impone 4-spazio. Sono (era, forse) abituato alle schede da C / C ++. Ma con un IDE correttamente impostato, la differenza diventa minima.

Usa gli spazi al posto delle schede, per il solo motivo che farai più soldi :)

Rif .: Gli sviluppatori che usano gli spazi fanno di più Soldi rispetto a quelli che usano le schede (post sul blog Stack Overflow).

Quindi, qui sto leggendo tutte le risposte e mi chiedo come posso conformarmi a PEP-8 senza il fastidio di battere ripetutamente il mio pulsante backspace solo per rimuovere il rientro, e guardo in basso la mia tastiera da gioco Logitech con tutti i suoi fantastici pulsanti macro e una lampadina si illumina nella mia testa.

Ho aperto il software Logitech, definito un paio di macro per i pulsanti proprio accanto al pulsante della scheda e il problema è stato risolto.

Un pulsante aggiunge quattro spazi e l'altro fa backspace quattro volte. Stupefacente. Semplicemente fantastico. Così facile premere i pulsanti anche con il mio mignolo.

Vedi, dai un'occhiata: " " < - quattro spazi! Con la semplice pressione di un pulsante! Se potessi mostrarti i backspaces, lo farei anche io. Prendi una tastiera Logitech G105 e tutti i tuoi problemi spariranno!

Sto solo iniziando, ma trovo molto più facile usare le tab che gli spazi, e non capisco solo la promozione PEP-8 degli spazi. Sublime Text 2 fa un ottimo lavoro nel visualizzare le schede con la linea tratteggiata verticale bianca e mentre ci sono casi in cui mescolo uno o due spazi per allineare elementi di un elenco o dizionario, non ho riscontrato una situazione in cui ciò sarebbe essere dannoso.

Adoro le schede ma è in qualche modo incompatibile con un'altra regola che mi piace: il limite di 80 colonne.

Se si scelgono 4 schede spazi e si inseriscono 10 schede, allora rimane spazio per 40 caratteri per soddisfare il limite di 80 colonne. Se un altro programmatore preferisce 8 tab di spazi, la stessa riga apparirà lunga 120 caratteri e non apparirà come una riga valida di 80 colonne!

Se vuoi definire un limite di 80 colonne, devi scegliere una lunghezza per una scheda. In questo caso avere x spazi o una linguetta di lunghezza x non fa davvero la differenza.

Modifica: thread correlato: Mantenimento della lunghezza massima della linea Quando si utilizzano le schede anziché gli spazi?

Penso che uno dei principali vantaggi dell'uso degli spazi sia la rimozione della variabilità nel modo in cui il codice sorgente viene reso attraverso la pletora di strumenti esterni che devono interagire con la fonte al di là dell'editor scelto e delle impostazioni che lo hanno configurato a.

Come alcuni esempi concreti considerano il rendering dei docstring di Python in una descrizione in Codice Visual Studio o in uno strumento diff come Beyond Compare o WinMerge , strumenti di copertura delle prestazioni o del codice, ecc. Fondamentalmente tutti questi vari altri strumenti di interfaccia possono avere impostazioni diverse per come vengono interpretate le schede e può essere noioso e talvolta disorientante nel trovare cose molto diverse o spinte fuori dallo schermo tra i set di strumenti in cui puoi immergerti e uscire.

In poche parole si definisce l'allineamento nella sorgente piuttosto che lottare su una configurazione uniforme per la suite di strumenti nel proprio arsenale. Gli spazi sono interpretati rigorosamente in un carattere monospace per fornire un allineamento affidabile e coerente per l'intera gamma di strumenti a causa della definizione del carattere, non dell'implementazione / configurazione del rendering di una scheda di terze parti.

Un altro aspetto è quello di copiare l'origine delle schede principali da eseguire in un terminale in cui il carattere della scheda può attivare un completamento involontario della scheda. Ad esempio, se copi la seguente sorgente Python (schede utilizzate come rientro),

cmd_create_db = '''CREATE TABLE test (
    Col1 INTEGER,
    Col2 INTEGER,
    Col3 TEXT)'''

potresti vedere qualcosa come segue (visto nel terminale integrato di Visual Studio Code) ...

>>> cmd_create_db = '''CREATE TABLE test (
... .DS_StoreCol1 INTEGER,
... .DS_StoreCol2 INTEGER,
... .DS_StoreCol3 TEXT)'''
>>> cmd_create_db
'CREATE TABLE test (\n.DS_StoreCol1 INTEGER,\n.DS_StoreCol2 INTEGER,\n.DS_StoreCol3 TEXT)'

(A parte: mi ero chiesto se questa osservazione di coerenza tra gli strumenti fosse un segno di una mente discriminante di uno sviluppatore acuto che cerca di ordinare al mondo che potrebbe indicare un indizio sulla differenza salariale trovata nello Stack & nbsp; Overflow .)

Uso due rientri di spazio e un editor (kwrite) che inserisce spazi anziché tab mentre premo il tasto tab.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow