The Invent with Python Blog

The Zen of Python di Tim Peters sono 20 linee guida per la progettazione del linguaggio Python. Il tuo codice Python non deve necessariamente seguire queste linee guida, ma sono buone da tenere a mente. Lo Zen di Python è un uovo di Pasqua, o scherzo nascosto, che appare se si esegue import this:

>>> import thisThe Zen of Python, by Tim PetersBeautiful is better than ugly.Explicit is better than implicit.Simple is better than complex.Complex is better than complicated.Flat is better than nested.Sparse is better than dense.Readability counts.Special cases aren't special enough to break the rules.Although practicality beats purity.Errors should never pass silently.Unless explicitly silenced.In the face of ambiguity, refuse the temptation to guess.There should be one-- and preferably only one --obvious way to do it.Although that way may not be obvious at first unless you're Dutch.Now is better than never.Although never is often better than *right* now.If the implementation is hard to explain, it's a bad idea.If the implementation is easy to explain, it may be a good idea.Namespaces are one honking great idea -- let's do more of those!

NOTA: misteriosamente, solo 19 delle linee guida sono scritte. Guido van Rosum riferito ha detto che l “aforisma mancante 20 è” qualche bizzarro Tim Peters in-scherzo.”

Alla fine, queste linee guida sono opinioni che possono essere argomentate a favore o contro. Come tutti i buoni set di codici morali, a volte si contraddicono per fornire la massima flessibilità. Ecco la mia interpretazione di questi aforismi:

Bello è meglio che brutto.

I programmatori spesso scrivono rapidamente il codice senza preoccuparsi della leggibilità. Mentre il codice non deve essere leggibile, il codice del linguaggio Python stesso deve essere pensato, coerente e una gioia da usare. Naturalmente, non tutti gli script devono essere belli, e la bellezza è soggettiva, ma gran parte della popolarità di Python è il risultato di essere così facile da lavorare.

Esplicito è meglio di implicito.

” Questo aforisma è autoesplicativo”, sarebbe una spiegazione terribile per qualsiasi aforisma. Allo stesso modo, è meglio che il codice sia dettagliato ed esplicito. Dovresti evitare di nascondere la funzionalità del codice dietro le caratteristiche del linguaggio oscure che richiedono familiarità per comprendere appieno.

Semplice è meglio di complesso. Complesso è meglio che complicato.

Questi due aforismi ci ricordano che costruire tutto può essere fatto con tecniche semplici o complesse. Con un semplice problema, come la costruzione di una casetta per gli uccelli, una soluzione semplice è migliore. Costruire un motore diesel, d’altra parte, è un problema complesso che richiede tecniche complesse. Anche se si potesse tecnicamente fare un motore diesel treno utilizzando tecniche birdhouse, probabilmente si finirebbe con un complicato, Rube Goldberg disposizione delle parti birdhouse che non sarebbe una soluzione ideale. Preferisci la semplicità alla complessità, ma conosci i limiti della semplicità.

Flat è meglio di nidificato.

I programmatori amano organizzare le cose in categorie, in particolare le categorie che contengono sottocategorie che contengono altre sottocategorie. Queste gerarchie spesso non aggiungono organizzazione tanto quanto aggiungono burocrazia. Va bene avere codice in un solo modulo o classe di livello superiore invece di dividere su più sottomoduli o sottoclassi. Se crei pacchetti e moduli che richiedono codice come import spam.eggs.bacon.ham.foo.bar, stai rendendo il tuo codice troppo complicato.

Sparse è meglio di denso.

I programmatori spesso amano stipare quante più funzionalità in meno codice possibile, come i one-liner come il seguente: print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 . While code like this may impress their friends, it'll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.

La leggibilità conta.

Mentre strcmp() può ovviamente significare la funzione “string compare” a qualcuno che ha programmato in C dal 1970, i computer moderni hanno abbastanza memoria per scrivere il nome completo della funzione. Non far cadere le vocali dai tuoi nomi o scrivere codice eccessivamente conciso. Il codice viene letto più spesso di quanto sia scritto, quindi il codice esplicito e leggibile è più importante del codice conciso e non documentato.

I casi speciali non sono abbastanza speciali da infrangere le regole. Anche se la praticità batte la purezza.

Questi due aforismi, che si presentano come un insieme, si contraddicono a vicenda. La programmazione è piena di” best practice ” che i programmatori dovrebbero cercare nel loro codice. Battiscopa queste pratiche per un hack veloce può essere allettante, ma può portare a nido di un topo di incoerente, codice illeggibile. Tuttavia, piegarsi all’indietro per aderire alle regole può comportare un codice altamente astratto e illeggibile. Il tentativo del linguaggio di programmazione Java di adattare tutto il codice al suo paradigma orientato agli oggetti spesso si traduce in un sacco di codice standardizzato anche per il programma più piccolo. Camminare la linea tra questi due aforismi diventa più facile con l’esperienza. E col tempo, non solo imparerai le regole, ma imparerai anche quando romperle.

Gli errori non dovrebbero mai passare in silenzio. A meno che non sia esplicitamente messo a tacere.

Solo perché i programmatori spesso ignorano i messaggi di errore non significa che il programma dovrebbe smettere di emetterli. Gli errori silenziosi possono verificarsi quando le funzioni restituiscono codici di errore o None invece di generare eccezioni. Questi due aforismi ci dicono che è meglio per un programma fail fast e crash piuttosto che mettere a tacere l’errore e continuare a eseguire il programma. I bug che inevitabilmente si verificano in seguito saranno più difficili da eseguire il debug poiché sono lontani dalla causa originale. Anche se puoi sempre scegliere di ignorare esplicitamente gli errori causati dai tuoi programmi, assicurati di fare la scelta consapevole di farlo.

Di fronte all’ambiguità, rifiuta la tentazione di indovinare.

I computer hanno reso gli esseri umani superstiziosi: per esorcizzare i demoni nei nostri computer eseguiamo il sacro rituale di spegnerli e poi accenderli. Presumibilmente questo risolverà qualsiasi problema misterioso. Tuttavia, i computer non sono magici. Se il tuo codice non funziona, c’è una ragione e solo un pensiero attento e critico lo risolverà. Rifiuta la tentazione di provare ciecamente soluzioni fino a quando qualcosa sembra funzionare; spesso hai semplicemente mascherato il problema piuttosto che risolverlo.

Ci dovrebbe essere uno-e preferibilmente solo un-modo ovvio per farlo.

Questa è una bordata contro il motto del linguaggio di programmazione Perl, ” C’è più di un modo per farlo!”Si scopre che avere tre o quattro modi diversi di scrivere codice che fa la stessa cosa è un’arma a doppio taglio: hai flessibilità nel modo in cui scrivi il codice, ma ora devi imparare ogni modo possibile che potrebbe essere stato scritto per leggerlo. Questa flessibilità non vale lo sforzo 3x o 4x necessario per imparare un linguaggio di programmazione.

Anche se in questo modo potrebbe non essere ovvio all’inizio a meno che tu non sia olandese.

Questa linea è uno scherzo. Guido van Rossum, il creatore e BDFL (Dittatore benevolo per la vita) di Python, è olandese. Tuttavia, nemmeno questo aforisma ha impedito a Python di incorporare tre diversi modi di formattare le stringhe.

Ora è meglio che mai. Anche se mai è spesso meglio di * destra * ora.

Questi due aforismi ci dicono che il codice che si blocca o viene catturato in loop infiniti è ovviamente peggiore del codice che non lo fa. Tuttavia, è quasi certamente meglio aspettare che il tuo programma finisca piuttosto che farlo finire troppo presto con risultati errati.

Se l’implementazione è difficile da spiegare, è una cattiva idea. Se l’implementazione è facile da spiegare, potrebbe essere una buona idea.

Python si sforza di rendere il lavoro del programmatore più facile piuttosto che ospitare il computer in modo che un programma funzioni più velocemente. E i programmi devono essere comprensibili non solo dal programmatore che lo ha scritto, ma anche da altri programmatori che mantengono il codice. Questi due aforismi ci ricordano che se il codice “ad alte prestazioni” è così complicato da essere impossibile per i programmatori capire ed eseguire il debug, allora è un codice errato. Ma ahimè, solo perché è facile spiegare il codice di un programma a qualcun altro non significa che non sia un codice errato. La programmazione è difficile.

Gli spazi dei nomi sono una grande idea—facciamone di più!

Gli spazi dei nomi (e anche gli ambiti globali e locali) sono la chiave per impedire che i nomi in un modulo o ambito entrino in conflitto con i nomi in un altro. Ma ricorda anche che flat è meglio di nested: per quanto grandi siano, gli spazi dei nomi dovrebbero essere fatti solo per prevenire conflitti di denominazione e non per aggiungere categorizzazione inutile.

Come tutte le opinioni sulla programmazione, quelle che ho scritto qui possono essere contestate o semplicemente irrilevanti per la tua situazione. Discutere su come il codice dovrebbe essere scritto è raramente produttivo come pensi che sia. (A meno che tu non stia scrivendo un intero libro pieno di opinioni di programmazione.)