Ci sono delle insidie ??nell'uso degli spazi bianchi in Python?

https://stackoverflow.com/questions/637295

10-07-2019
|

Domanda

Al momento non ho mai avuto problemi con gli spazi bianchi in Python (anche se l'ho usato solo in due progetti ed ero l'unico programmatore). Quali sono alcune potenziali insidie ??con spazi bianchi e rientri in Python per qualcuno che impara la lingua?

Soluzione

sì, ci sono alcune insidie, ma la maggior parte delle volte, in pratica, si rivelano nemici mulini a vento dello stile Quixotic , cioè immaginario, e nulla di cui preoccuparsi nella realtà.

Stimerei che le insidie ??che è più probabile incontrare siano (compresi i passi di mitigazione identificati):

lavorare con altri a.k.a. collaborazione

a. se ne hai altri che per qualsiasi motivo si rifiutano di aderire a PEP 8 , quindi potrebbe essere una seccatura mantenere il codice. Non l'ho mai visto in pratica una volta che gli faccio notare che la convenzione quasi universale per Python è livello di rientro == quattro spazi

b. fai in modo che chiunque / chiunque lavori con te per accettare la convenzione e fargli capire come fare in modo che il proprio editor lo faccia automaticamente (o meglio, se usi lo stesso editor, mostra loro come configurarlo) in modo tale da copiare e incollare e roba funziona e basta .
dover investire in un "decente" un editor diverso da quello che preferisci attualmente, se il tuo attuale editor preferito non è compatibile con Python - non è in realtà una trappola, più un requisito di investimento per evitare le altre insidie ??menzionate associate a copia e incolla, re-factoring, ecc. smetti di usare Blocco note e ti ringrazierai al mattino.

a. la tua efficienza nella modifica del codice sarà molto più elevata in un editor che comprende python

b. la maggior parte degli editor di codice moderni gestiscono decentemente python. Io stesso preferisco GNU Emacs e le versioni recenti sono dotate di un eccellente supporto python-mode pronto all'uso. Ci sono molti altri editor da esplorare , incluse molte alternative gratuite e IDE .

c. Python stesso viene fuori dalla scatola con un "intelligente" editor python, inattivo . Dai un'occhiata se non hai familiarità, poiché è probabilmente già disponibile con l'installazione di Python e potrebbe persino supportare python meglio del tuo attuale editor. PyCrust è un'altra opzione per un editor Python implementato in Python ed è incluso in wxPython.
alcuni ambienti di generazione di codice o modelli che incorporano python (pensa alla generazione di HTML o alle app CGI / WSGI di Python) possono avere delle stranezze

a. la maggior parte di loro, se toccano Python, hanno adottato delle misure per ridurre al minimo la natura di Python come problema, ma viene comunque visualizzata di tanto in tanto.

b. in questo caso, acquisire familiarità con i passaggi che gli autori del framework hanno già adottato per ridurre al minimo l'impatto e leggere i loro suggerimenti ( e sì ne avranno alcuni se mai incontrati nel loro progetto ) e sarà semplice evitare le insidie ??legate a Python su questo.

Altri suggerimenti

Può essere fonte di confusione in alcuni editor in cui una riga è rientrata con spazi e la successiva è rientrata con una scheda. Questo è confuso poiché il rientro sembra lo stesso ma causa un errore.

Anche quando il tuo codice di copia, se il tuo editor non ha una funzione per indentare interi blocchi, potrebbe essere fastidioso correggere tutto il rientro.

Ma con un buon editor e un po 'di pratica, questo non dovrebbe essere un problema. Personalmente mi piace molto il modo in cui Python utilizza gli spazi bianchi.

Questo in realtà mi ha tenuto lontano da Python per un po '. Provenendo da un forte background C, mi sentivo come se stessi guidando senza una cintura di sicurezza.

È stato esasperante quando stavo provando a riempire una libreria di frammenti nel mio editor con classi boilerplate, di uso frequente. Imparo meglio con l'esempio, quindi stavo afferrando quanti più frammenti interessanti possibile con l'obiettivo di scrivere un programma utile durante l'apprendimento.

Dopo aver preso l'abitudine di riformattare tutto ciò che ho preso in prestito, non è stato poi così male. Ma sembrava ancora molto imbarazzante. Mi sono dovuto abituare a un rientro PLUS del linguaggio tipizzato in modo dinamico che controlla il mio codice.

È stato un bel salto per me :)

Quando guardo il codice C e Java, è sempre ben rientrato.

Sempre. Bell '. Rientrato.

Chiaramente, le persone C e Java passano molto tempo a sistemare bene lo spazio bianco.

Lo stesso vale per i programmatori Python.

I delimitatori di blocchi di spazi bianchi impongono una certa quantità di formattazione del codice, il che sembra irritare alcuni programmatori. Alcuni nel nostro negozio sembrano avere l'atteggiamento di essere troppo occupati o che non possono preoccuparsi di prestare attenzione agli standard di formattazione e un linguaggio che li costringe a strofinarli. A volte le stesse persone lamentano quando gli altri non seguono gli stessi schemi di mettere le parentesi graffe su una nuova linea;)

Trovo che il codice Python dal web sia più comunemente "leggibile", poiché è presente questo requisito di formattazione minore. IMO, questo requisito è una funzione molto utile.

IIRC, Haskell, OCaml (#light) e F # non usano gli spazi bianchi allo stesso modo? Per qualche motivo, non ho visto lamentele su queste lingue.

Molto tempo fa, in un ambiente molto, molto lontano, c'erano lingue (come i giochi di ruolo) che dipendevano dalla struttura a colonne delle schede perforate. Si trattava di un sistema noioso e noioso, che portava a molti errori e linguaggi più recenti come BASIC, Pascal e così via sono stati progettati senza questa dipendenza.

Una generazione di programmatori è stata addestrata su queste lingue e ha ripetutamente detto che la libertà di mettere qualsiasi cosa ovunque fosse una caratteristica meravigliosa delle nuove lingue, e dovrebbero essere grati. La libertà è stata utilizzata, abusata e calibrata (cfr. IOCC ) per molti anni.

Ora il pendolo ha iniziato a oscillare all'indietro, ma molte persone ricordano ancora che la disposizione forzata è in qualche modo vaga e resiste.

IMHO, la cosa da fare è lavorare con le lingue alle loro condizioni, e non rimanere impazziti in battaglie con gusti che non soddisfano molto.

Quando i programmatori python non seguono la convenzione comune di " Usa 4 spazi per livello di rientro " definito in PEP 8 . ( Se sei un programmatore python e non l'hai letto, per favore fallo )

Quindi si verificano problemi di copia incolla.

Alcune persone dicono che non gradiscono il rientro in pitone, perché può causare errori, che sarebbe immensamente difficile da rilevare nel caso in cui le schede e gli spazi siano mescolati. Ad esempio:

1 if needFrobnicating:
2    frobnicate()
3 update()

A seconda della larghezza della scheda, la riga 3 potrebbe apparire nello stesso blocco della riga 2 o nel blocco che la racchiude. Ciò non causerà errori di runtime o compilazione, ma il programma farebbe cose inaspettate.

Anche se ho programmato in Python per 10 anni e non ho mai visto un errore causato dalla combinazione di schede e spazi

Scegli un buon editor. Vorresti funzionalità come:

Rientro automatico che imita l'ultima riga rientrata
Rientro automatico che puoi controllare (tab contro spazi)
Mostra i caratteri degli spazi bianchi
Rilevamento e imitazione della convenzione degli spazi bianchi durante il caricamento di un file

Ad esempio, Vim mi consente di evidenziare le schede con queste impostazioni:

set list
set listchars=tab:\|_
highlight SpecialKey ctermbg=Red guibg=Red
highlight SpecialKey ctermfg=White guifg=White

Che può essere disattivato in qualsiasi momento utilizzando:

set nolist

IMO, non mi piacciono le impostazioni dell'editor che convertono le schede in spazi o viceversa, perché finisci con un mix di schede e spazi, che può essere brutto.

Pensavo che i problemi dello spazio bianco fossero solo una questione di abituarsi.

Qualcuno ha sottolineato alcuni gravi difetti con l'indentazione di Python e penso che siano abbastanza validi e una comprensione subconcisa di questi è ciò che rende nervosi i programmi con esperienza su tutto: -

Taglia e incolla non funziona più! Non è possibile tagliare il codice della piastra della caldaia da un'app e rilasciarlo in un'altra app.
Il tuo editor diventa impotente per aiutarti. Con C / Jave ecc. Ci sono due cose in corso sul "quotazione ufficiale". rientro tra parentesi graffe e, "non ufficiale" rientro dello spazio bianco. La maggior parte degli editor è in grado di riformattare il rientro dello spazio bianco in modo che corrisponda al raggruppamento di parentesi graffe, il che fornisce un indizio visivo della stringa che qualcosa non va se il rientro non è quello che ti aspettavi. Con i pitoni "lo spazio è sintassi" paradigma che l'editor non può aiutarti.
Il puro dolore di introdurre un'altra condizione nella logica già complessa. Aggiungerne un altro, se non altro, in una condizione esistente comporta un sacco di sciocchi errori inclini all'inserimento di spazi su molte linee linea a mano.
Il refactoring è un incubo. Spostare blocchi di codice nelle tue classi è così doloroso che è più facile sopportare un "errato". struttura di classe piuttosto che trasformarla in una migliore.

Se usi Eclipse come IDE, dovresti dare un'occhiata a PyDev; gestisce automaticamente rientro e spaziatura. Puoi copiare e incollare da fonti a spaziatura mista e li convertirà per te. Da quando ho iniziato a studiare la lingua, non ho mai pensato una volta alla spaziatura.

Ed è davvero un non-problema; programmatori sani di mente rientrano comunque. Con Python, fai solo quello che hai sempre fatto, meno dover digitare e abbinare le parentesi graffe.

Le insidie ??

Può essere fastidioso pubblicare frammenti di codice su siti Web che ignorano il rientro.
È difficile capire come funzioni anonime multilinea (lambda) possano adattarsi alla sintassi della lingua.
È difficile incorporare Python nei file HTML per creare modelli nel modo in cui PHP o C # possono essere incorporati nelle pagine PHP o ASP.NET. Ma non è necessariamente il modo migliore per progettare modelli.
Se il tuo editor non ha comandi sensibili per il rientro del blocco ed è superato, sarà noioso riallineare il codice.

I vantaggi

Forza persino i programmatori pigri a produrre codice leggibile. Ho visto esempi di codice in lingua che ho dovuto impiegare ore a riformattare per poterlo leggere ...
I programmatori Python non hanno bisogno di passare ore a discutere se le parentesi graffe debbano andare alle estremità delle linee in stile K & amp; o sulle linee da sole in stile Microsoft.
Libera i caratteri di parentesi graffe da utilizzare per il dizionario e imposta le espressioni.
È automaticamente abbastanza leggibile

Il problema è che in Python, se si utilizzano spazi per rientrare i blocchi di base in un'area di un file e le schede per rientrare in un altro, si ottiene un errore di runtime. Questo è abbastanza diverso dai punti e virgola in C.

Questa non è davvero una domanda di programmazione, vero?

L'unico problema che abbia mai avuto sono i piccoli fastidi quando uso il codice che ho scritto prima di decidere se mi piacciono le schede o gli spazi o il taglio e la pubblicazione di codice da un sito Web.

Penso che i redattori più decenti in questi giorni abbiano un'opzione di conversione da tabs a spazi e back. Textmate certamente.

Oltre a ciò, il rientro non mi ha mai causato problemi.

Se stai usando emacs, imposta una lunghezza di tabulazione dura di 8 e una lunghezza di tabulazione morbida di 4. In questo modo verrai modificato con qualsiasi carattere di tabulazione estraneo. Dovresti sempre utilizzare 4 spazi anziché le schede.

Uno svantaggio che ho riscontrato come principiante con Python che stava dimenticando di impostare softtab nei miei editor mi ha dato molti problemi.

Ma dopo un anno di serio uso della lingua non sono più in grado di scrivere codice scarsamente indentato in qualsiasi altra lingua.

No, direi che è una cosa a cui non posso trovare cadute. Sì, è senza dubbio irritante per alcuni, ma è solo perché hanno un'abitudine diversa riguardo al loro stile di formattazione. Imparalo presto e rimarrà. Guarda quante discussioni abbiamo su una questione di stile in linguaggi come C, Cpp, Java e simili. Non vedi quelle (inutili, senza dubbio) discussioni su linguaggi come Python, F77 e alcuni altri citati qui che hanno un "fisso" stile di formattazione.

L'unica cosa che è variabile sono gli spazi rispetto alle schede (può essere modificato con un piccolo problema con qualsiasi buon editor) e la quantità di account delle schede degli spazi per (può essere cambiato senza alcun problema con un buon editor). Ecco ! Discussione sullo stile completata.

Ora posso fare qualcosa di utile :)

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow