I programmatori Python trovano scomodo il problema degli spazi bianchi? [chiuso]


11

Molti programmatori, al primo incontro con Python, vengono immediatamente rimossi dal significato dello spazio bianco. Ho sentito una serie di ragioni per cui questo è scomodo, ma non ho mai sentito una lamentela da un programmatore Python.

Certo, non ho incontrato molti programmatori Python, poiché ho trascorso la mia carriera nel mondo Java.

Quindi la mia domanda è per quelli di voi che hanno partecipato a un grande progetto Python (più di 3 mesi, con Python come lingua principale utilizzata): hai riscontrato che il problema degli spazi bianchi è scomodo e continuamente fastidioso? O è stato un problema una volta entrato nel flusso?

Non sto ponendo la domanda perché sono a favore o contro Python, o a favore o contro il suo uso di spazi bianchi. Mi piace Python, ma non l'ho mai usato per qualcosa di grosso.

Si prega di non fornire speculazioni se non si ha esperienza in Python.


2
Userebbero la lingua se lo facessero? Non lo farei. I requisiti di sintassi fastidiosi / che distraggono sono una delle cose che potrebbero farmi scegliere una lingua diversa per un progetto (supponendo, ovviamente, che io possa scegliere).

da quando lo spazio bianco è un problema? :-)
Kugel

22
Troviamo scomodo che tutti gli altri continuino a mostrarlo. Non ci pensiamo mai.
Winston Ewert,

Il problema dello spazio bianco non è diverso da anni fa: OCCAM2 aveva uno spazio bianco significativo. Non è stato un grosso problema.
quick_now

4
L'unica volta che l'ho mai trovato fastidioso è quando copia e incolla il codice online che è stato scritto usando spazi anziché tabulazioni (o viceversa), causando errori di sintassi letteralmente invisibili
Cameron

Risposte:


14

C'è solo un caso in cui trovo che lo spazio bianco sia fastidioso, e cioè quando si modifica il codice esistente in modo che un blocco di codice debba diventare più o meno rientrato rispetto a prima (ad esempio, aggiungendo o eliminando un carattere if:precedente al codice). Quando scrivi in ​​una lingua come C, aggiungi semplicemente ifuna coppia di parentesi graffe e (in Emacs, o immagino un buon editor) premi Tab per consentire all'editor di correggere automaticamente il rientro. In Python, devi farlo da solo. Naturalmente, ci sono scorciatoie dell'editor per farlo da soli, quindi non è poi così male, ma la perdita di ridondanza impone un leggero onere aggiuntivo al programmatore.

Nel complesso, è una vittoria, anche se solo per impedire che metà del mio schermo venga riempito con linee come le seguenti:

         }
      }
   }
}

1
In qualsiasi editor ragionevole che parla Python, esiste un modo molto semplice per riutilizzare il blocco di codice. In Wing IDE, seleziono semplicemente il blocco e premo Tab (o Shift-Tab per ridurre il livello di rientro).
Adam Crossland,

1
Sì, in Emacs seleziono il blocco e premo C-c >o C-c <. Tuttavia, devi ancora farlo da solo. Per dirla in altro modo, poiché gli spazi bianchi e la logica del codice non sono ridondanti, non puoi semplicemente selezionare un blocco gigante e chiamare M-x indent-region(o qualunque sia la versione del tuo editor) per indentare tutto "correttamente".
dfan,

6
@Adam, un buon editor semplifica la modifica del livello di rientro. Ma in una lingua di parentesi graffe, è possibile incollare il nuovo codice e premere il tasto preferito per riutilizzare il file. Tada! Il rientro è corretto. In Python, devi incollare, selezionare, indent / dedent. Non è molto, ma qui c'è una piccola vittoria per le parentesi graffe.
Winston Ewert,

@ Winston - deve essere il tuo editore. Se il codice che incolli è di per sé indentet corretto, se esce di qualche livello troppo a destra / a sinistra è solo una questione di digitazione (MAIUSC +) per allinearlo di conseguenza - non è una vera differenza premere il tasto reindentizzare il file. Inoltre - non copiare / incollare il codice :)
Ingo

1
@Winston: anche i blocchi di rientro di Notepad ++ quando uso Tab e Shift-Tab, non ho ancora trovato la scorciatoia di VIM, ma non la uso abbastanza credo: p
Matthieu M.

50

Adoro lo spazio bianco significativo di Python. Per me è l'esempio perfetto di DRY a livello sintattico. Il modo leggibile dall'uomo per indicare dove inizia e finisce un blocco di codice è con il rientro. Se vuoi che il tuo codice sia leggibile, devi rientrarlo indipendentemente dalla lingua. È sciocco fare in modo che il programmatore specifichi queste informazioni due volte, una volta per il compilatore / interprete e una volta per gli umani. Inoltre, il rientro in linguaggi simil-C è simile a un commento: ha lo scopo di migliorare la comprensibilità ma il suo significato non è applicato dal compilatore / interprete e può non essere sincronizzato con il significato reale (dove sono le parentesi graffe) molto facilmente, offuscante piuttosto che chiarificante.


8
+1 per Non ripetere te stesso. La buona pratica è di indentare il codice in modo che rifletta la struttura a blocchi, quindi perché anche i marcatori di inizio / fine?
Steve314,

12

Gli spazi bianchi significativi sono effettivamente convenienti per me. Mi fa scrivere di meno. Formatta il codice in modo ordinato e piuttosto inequivocabile. Per questo motivo, rende il codice più leggibile.

(Mi piacciono gli spazi bianchi significativi anche in Haskell, per le stesse ragioni.)


1
Avrei condiviso la mia esperienza positiva anche con gli spazi bianchi di Haskell, ma FarmBoy ha insistito sul fatto che si dovrebbe avere 3 mesi di esperienza con Python, qualsiasi altra cosa era la speculazione. :-)
Ingo

1
La mia esperienza con Python è dal 1998, quindi la mia risposta probabilmente si qualifica :) (Peccato che la mia esperienza con Haskell sia molto più breve.)
9000

@ 9000 Anche se Haskell è venuto prima di Python! : D
pradyunsg,

8

Quando ho usato Python per la prima volta, la cosa degli spazi bianchi era nuova e quindi una restrizione fastidiosa.

Adesso non me ne accorgo nemmeno. Uso Python da 11 mesi.


5

Prima di tutto, i miei linguaggi pane e burro sono Python, SQL e Java. Adoro lo spazio bianco di Python: è meno sintassi e digitazione e costringe le persone a scrivere codice leggibile e ben formattato. OTOH, odio la verbosità di Java, tanto che uso effettivamente Python per generare tutto il plateplate che devo scrivere in Java, il che impressiona tutti i miei colleghi Java che sono sorpresi dalla mia produttività.

L'unico grande avvertimento, tuttavia, è quando si copia / incolla il codice dal web - spesso causa spazi e schede misti che richiedono un ulteriore passaggio per ripulire, e di solito prendo solo dopo un'eccezione di runtime.


Dire al tuo editor di sintassi evidenziare le schede come errori può aiutare molto - per vim che uso highlight link RedundantSpaces Error | au BufEnter,BufRead * match RedundantSpaces "\t" | au BufEnter,BufRead * match RedundantSpaces "[[:space:]]\+$"nel mio vimrc
Daenyth

4

Se un programmatore è infastidito dal significato degli spazi bianchi, probabilmente non diventerà un programmatore Python.


1
Ho sentito un bel po 'di persone che predicano Python che affermano di avere avuto problemi con The Whitespace Thing (tm), ma che dopo un po' sono piaciute. Dalla mia osservazione, sembra che quando più persone si uniscono a una discussione su questo argomento, la propensione di uno di loro a raccontare una storia simile si avvicina a una. (Modifica: dimostrato immediatamente dalla seconda risposta ...)

@delnan, posso iscrivermi a questo.
Ingo

3

Scommetto che troveresti una notevole sovrapposizione tra le persone che hanno un problema con spazi bianchi significativi e quelle che non hanno esperienza con un buon editor di testi per programmatori, come Emacs, che gestisce la maggior parte dei rientri senza il loro coinvolgimento.

In ogni caso, una volta che hai interiorizzato Python, non è più un problema; infatti, la sua concisione e il piccolo spazio che occupa sullo schermo diventano un grande vantaggio per la leggibilità. Dato che ho usato principalmente Python, trovo che le lingue in cui vi sia più ridondanza (ad es. Java e C #) siano difficili da disciplinare per la scrittura. Mettere le parentesi graffe attorno al codice la cui rientranza rende già chiara la sua struttura grattugie sui miei nervi.


3

Per la codifica effettiva, non è affatto scomodo, ma effettivamente vantaggioso (vedi la risposta di dsimcha).

Può essere fastidioso quando si tratta di tecnologie di comunicazione che non rispettano i principali spazi bianchi (come molti forum Web non orientati alla programmazione e anche quando si incorpora il codice Python in un linguaggio diverso, come i linguaggi di template HTML), anche se lo vedo come più un difetto negli strumenti che rimuovono gli spazi bianchi che un difetto in Python, è vero che i linguaggi ridondanti che esprimono due volte la struttura del codice sono meglio equipaggiati per gestire tali ambienti distruttivi (poiché puoi incollare il codice in un editor e reindent in base ai marcatori strutturali espliciti, o semplicemente non importa se il codice viene eseguito solo anziché letto dagli umani).


2

Non trovo fastidioso lo spazio bianco. Trovo che la mancanza o l'inconsistenza del rientro sia molto fastidiosa in altre lingue. Capisco che questo problema è uno dei problemi che lo stile intende risolvere.

Python non è una delle mie lingue principali.

Trovo che la gestione di schede e spazi nel rientro sia fastidiosa in alcune occasioni. Ciò può causare problemi quando si passa da un editor a un altro o quando si modifica il codice scritto da qualcun altro. Di solito è banale da risolvere.


1
mescolare schede e spazio nell'indentazione di Python è la strada più breve per l'inferno: p
Matthieu M.

@Mattieu: Sicuramente, questo è il mio fastidio.
BillThor,

1

Vengo da uno sfondo C # / Javascript / XBase in nessun ordine particolare, e nei miei dabbling con Python non è affatto una considerazione per me. È come un apparecchio in altre lingue: è così che funziona, metti le cose come dicono le regole e asciugare gli occhi è il mio atteggiamento.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.