The Invent with Python Blog

The Zen of Python av Tim Peters är 20 riktlinjer för utformningen av Python-språket. Din Python-kod behöver inte nödvändigtvis följa dessa riktlinjer, men de är bra att tänka på. Zen av Python är ett påskägg, eller dolda skämt, som visas om du kör 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!

notera: mystiskt, endast 19 av riktlinjerna skrivs ner. Guido van Rosum sa enligt uppgift att den saknade 20: e aforismen är ”något bisarrt Tim Peters skämt.”

i slutändan är dessa riktlinjer åsikter som kan argumenteras för eller emot. Liksom alla bra uppsättningar moraliska koder motsäger de sig ibland för att ge mest flexibilitet. Här är min egen tolkning av dessa aforismer:

vacker är bättre än ful.

programmerare skriver ofta kod snabbt utan oro för läsbarhet. Medan koden inte behöver vara läsbar måste koden för Python-språket vara genomtänkt, konsekvent och en glädje att använda. Naturligtvis behöver inte varje manus vara vackert, och skönhet är subjektivt, men mycket av Pythons popularitet är ett resultat av att vara så lätt att arbeta med.

Explicit är bättre än implicit.

”denna aforism är självförklarande”, det skulle vara en fruktansvärd förklaring till någon aforism. På samma sätt är det bättre för kod att vara verbose och explicit. Du bör undvika att dölja kodens funktionalitet bakom obskyra språkfunktioner som kräver förtrogenhet för att fullt ut förstå.

enkel är bättre än komplex. Komplex är bättre än komplicerat.

dessa två aforismer påminner oss om att bygga allt kan göras med enkla eller komplexa tekniker. Med ett enkelt problem, som att bygga ett fågelhus, är en enkel lösning bättre. Att bygga en dieseltågmotor är å andra sidan ett komplext problem som kräver komplexa tekniker. Även om du tekniskt kunde göra en diesel tågmotor med hjälp av fågelholk tekniker, du förmodligen skulle sluta med en komplicerad, Rube Goldberg arrangemang av fågelholk delar som inte skulle vara en idealisk lösning. Föredrar enkelhet till komplexitet, men vet gränserna för enkelhet.

platt är bättre än kapslad.

programmerare älskar att organisera saker i kategorier, särskilt kategorier som innehåller underkategorier som innehåller andra underkategorier. Dessa hierarkier lägger ofta inte till organisation så mycket som de lägger till byråkrati. Det är okej att ha kod i bara en toppskiktsmodul eller klass istället för att dela upp över flera undermoduler eller underklasser. Om du gör paket och moduler som kräver kod som import spam.eggs.bacon.ham.foo.bar, gör du din kod för komplicerad.

gles är bättre än tät.

programmerare gillar ofta att klämma in så mycket funktionalitet i så lite kod som möjligt, till exempel one-liners som följande: 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.

läsbarhet räknas.

medan strcmp() uppenbarligen kan betyda funktionen ”string compare” till någon som har programmerat i C sedan 1970-talet, har moderna datorer tillräckligt med minne för att skriva ut hela funktionsnamnet. Släpp inte vokaler från dina namn eller skriv alltför kortfattad kod. Kod läses oftare än det är skrivet, så explicit, läsbar kod är viktigare än kortfattad, papperslös kod.

specialfall är inte tillräckligt speciella för att bryta mot reglerna. Även om praktiken slår renhet.

dessa två aforismer, som kommer som en uppsättning, motsäger varandra. Programmering är full av” bästa praxis ” som programmerare bör sträva efter i sin kod. Lister dessa metoder för en snabb hacka kan vara frestande, men kan leda till en råtta boet inkonsekvent, oläslig kod. Att böja sig bakåt för att följa regler kan dock resultera i mycket abstrakt, oläslig kod. Java-programmeringsspråkets försök att passa all kod till sitt objektorienterade paradigm resulterar ofta i massor av standardkod för även det minsta programmet. Att gå linjen mellan dessa två aforismer blir lättare med erfarenhet. Och med tiden lär du dig inte bara reglerna, utan lär dig också när du ska bryta dem.

fel ska aldrig passera tyst. Om inte uttryckligen tystas.

bara för att programmerare ofta ignorerar felmeddelanden betyder inte att programmet ska sluta avge dem. Tysta fel kan inträffa när funktioner returnerar felkoder eller None istället för att höja undantag. Dessa två aforismer säger att det är bättre för ett program att fail fast och krascha än att tysta felet och fortsätta köra programmet. Buggarna som oundvikligen händer senare kommer att bli svårare att felsöka eftersom de är långt ifrån den ursprungliga orsaken. Även om du alltid kan välja att uttryckligen ignorera de fel som dina program orsakar, var bara säker på att du gör det medvetna valet att göra det.

mot bakgrund av tvetydighet, vägra frestelsen att gissa.

datorer har gjort människor vidskepliga: för att utöva demonerna i våra datorer utför vi den heliga ritualen att stänga av dem och sedan på. Förmodligen kommer detta att lösa alla mystiska problem. Datorer är dock inte magiska. Om din kod inte fungerar, det finns en anledning och endast noggrann, kritiskt tänkande kommer att lösa det. Avvisa frestelsen att blint försöka lösningar tills något verkar fungera; ofta har du bara maskerat problemet snarare än löst det.

det bör finnas ett—och helst bara ett—uppenbart sätt att göra det.

Detta är en bred sida mot Perl-programmeringsspråkets motto, ” Det finns mer än ett sätt att göra det!”Det visar sig att ha tre eller fyra olika sätt att skriva kod som gör samma sak är ett tveeggat svärd: du har flexibilitet i hur du skriver kod, men nu måste du lära dig alla möjliga sätt det kunde ha skrivits för att läsa det. Denna flexibilitet är inte värt 3x eller 4x ansträngning som behövs för att lära sig ett programmeringsspråk.

även om det sättet kanske inte är uppenbart först om du inte är holländsk.

denna linje är ett skämt. Guido van Rossum, skaparen och Bdfl (välvillig diktator för livet) av Python, är holländare. Men inte ens denna aforism hindrade Python från att införliva tre olika sätt att formatera strängar.

nu är bättre än aldrig. Även om aldrig är ofta bättre än * just * nu.

dessa två aforismer berättar för oss att kod som hänger eller fastnar i oändliga slingor är uppenbarligen sämre än kod som inte gör det. det är dock nästan säkert bättre att vänta på att ditt program ska slutföras än att det slutar för tidigt med felaktiga resultat.

om implementeringen är svår att förklara är det en dålig ide. Om genomförandet är lätt att förklara kan det vara en bra ide.

Python strävar efter att göra programmerarens jobb enklare snarare än att rymma datorn så att ett program körs snabbare. Och program måste vara förståeligt inte bara av programmeraren som skrev det, men också av andra programmerare som behåller koden. Dessa två aforismer påminner oss om att om” högpresterande ” kod är så komplicerad att det är omöjligt för programmerare att förstå och felsöka, då är det dålig kod. Men tyvärr, bara för att det är lätt att förklara ett program kod till någon annan betyder inte att det inte är dålig kod. Programmering är svårt.

namnområden är en tutande bra ide-låt oss göra mer av dem!

namnområden (och även globala och lokala omfattningar) är nyckeln för att förhindra att namn i en modul eller omfattning strider mot namn i en annan. Men kom också ihåg att Platt är bättre än kapslad: så bra som de är, bör namnrymder endast göras för att förhindra namnkonflikter och inte lägga till onödig kategorisering.

liksom alla åsikter om programmering kan de som jag har skrivit här argumenteras mot eller helt enkelt vara irrelevanta för din situation. Att argumentera över hur kod ska skrivas är sällan så produktiv som du tror att den är. (Om du inte skriver en hel bok full av programmerings åsikter.)