Rientro Python in "righe vuote"

Question

Quale è il preferito ("." Indica lo spazio bianco)?

A)

def foo(): 
    x = 1 
    y = 2 
.... 
    if True: 
     bar() 

B)

def foo(): 
    x = 1 
    y = 2 

    if True: 
     bar() 

mia intuizione sarebbe B (che è anche quello che vim fa per me), ma vedo persone che utilizzano A) per tutto il tempo. È solo perché la maggior parte degli editori là fuori è rotta?

Answer 1

Il PEP 8 non sembra essere chiaro su questo problema, anche se le affermazioni su "righe vuote" potrebbero essere interpretate a favore di B. Il controllore di stile PEP 8 (pep8.py) preferisce B e avverte se si usa UN; tuttavia, entrambe le varianti sono legali. Il mio punto di vista è che, dal momento che Python interpreterà correttamente il codice in entrambi i casi, questo non ha molta importanza, e provare a farla rispettare sarebbe un sacco di lavoro per un guadagno molto scarso. Suppongo che se sei molto categorico a favore dell'uno o dell'altro puoi automaticamente convertire l'uno con l'altro. Provare a sistemare manualmente tutte queste linee, però, sarebbe un'impresa enorme e davvero non ne vale la pena, IMHO.

Answer 2

Emacs fa B) per me, ma davvero non credo che importi. A) significa che è possibile aggiungere una riga al rientro corretto senza alcuna tabulazione.

Answer 3

Quella riga vuota appartiene a foo(), quindi considererei lo A il più naturale. Ma immagino sia solo una questione di opinione.

Answer 4

Non chiamerei necessariamente il primo esempio "interrotto", perché so che alcune persone lo odiano quando il cursore "salta indietro" quando si sposta il cursore su o giù nel codice. Per esempio. Visual Studio (almeno 2008) impedisce automaticamente che ciò accada senza utilizzare alcun carattere di spaziatura su quelle righe.

Answer 5

Se si utilizza A, è possibile copiare incollare il blocco in guscio pitone, B otterrà errore rientro inaspettato.

Answer 6

La mia esperienza nello sviluppo open source è che non si dovrebbe mai lasciare spazi vuoti all'interno di righe vuote. Inoltre non si dovrebbe mai lasciare lo spazio bianco finale.

È una questione di etichetta di codice.

Answer 7

TextMate interrompe il blocco del collasso se si utilizza B, e preferisco A comunque poiché è più "logico".

Answer 8

Aggiunta di una corretta indentazione di righe vuote (stile A in questione) migliora notevolmente la leggibilità del codice con display spazi abilitato perché rende più facile da vedere se il codice dopo una riga vuota è parte dello stesso blocco di rientro o meno.

Per un linguaggio come Python, in cui non esiste un'istruzione finale o parentesi chiusa, sono sorpreso che questo non faccia parte di PEP. Si consiglia vivamente di modificare Python con spazi bianchi di visualizzazione, per evitare sia spazi bianchi finali che indentazioni miste.

Confrontare leggendo la seguente:

A)

def foo(): 
....x = 1 
....y = 2 
.... 
....if True: 
........bar() 

B)

def foo(): 
....x = 1 
....y = 2 

....if True: 
........bar() 

In Un, è molto più chiaro che le ultime due righe sono parte di foo. Questo è ancora più utile a livelli di rientro più elevati.

Answer 9

vi scoraggia implicitamente il comportamento in A poiché le navigazioni {/} non funzionano più come previsto. git lo scoraggia esplicitamente evidenziandolo in rosso quando si esegue git diff. Vorrei anche sostenere che se una linea contiene spazi non è una riga vuota.

Per questo motivo preferisco fortemente B. Non c'è niente di peggio che aspettarsi di saltare sei o così allineate con il movimento { e finire in cima a una classe def.