opfinderen med Python Blog

Python af Tim Peters er 20 retningslinjer for design af Python-sproget. Din Python-kode behøver ikke nødvendigvis at følge disse retningslinjer, men de er gode at huske på. Pythons højdepunkt er et påskeæg, eller skjult vittighed, der vises, hvis du løber 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!

Bemærk: mystisk er kun 19 af retningslinjerne skrevet ned. Guido van Rosum sagde angiveligt, at den manglende 20.aforisme er “en bisarr Tim Peters in-joke.”

i sidste ende er disse retningslinjer meninger, der kan argumenteres for eller imod. Som alle gode sæt moralske koder modsiger de undertiden sig selv for at give mest fleksibilitet. Her er min egen fortolkning af disse aforier:

smuk er bedre end grim.

programmører skriver ofte kode hurtigt uden bekymring for læsbarhed. Mens kode ikke behøver at være læsbar, skal selve Python-sprogets kode være gennemtænkt, konsistent og en glæde at bruge. Selvfølgelig skal ikke alle script være smukke, og skønhed er subjektiv, men meget af Pythons popularitet er et resultat af at være så let at arbejde med.

eksplicit er bedre end implicit.

“denne aforisme er selvforklarende”, det ville være en forfærdelig forklaring på enhver aforisme. På samme måde er det bedre for kode at være verbose og eksplicit. Du bør undgå at skjule kodens funktionalitet bag obskure sprogfunktioner, der kræver fortrolighed for fuldt ud at forstå.

enkel er bedre end kompleks. Kompleks er bedre end kompliceret.

disse to aforier minder os om, at opbygning af alt kan gøres ved hjælp af enkle eller komplekse teknikker. Med et simpelt problem, såsom at bygge et fuglehus, er en simpel løsning bedre. Opbygning af en dieseltogmotor er derimod et komplekst problem, der kræver komplekse teknikker. Selvom du teknisk set kunne lave en dieseltogmotor ved hjælp af birdhouse-teknikker, ville du sandsynligvis ende med et kompliceret Rube Goldberg-arrangement af birdhouse-dele, der ikke ville være en ideel løsning. Foretrækker enkelhed frem for kompleksitet, men kender grænserne for enkelhed.

flad er bedre end indlejret.

programmører elsker at organisere ting i kategorier, især kategorier, der indeholder underkategorier, der indeholder andre underkategorier. Disse hierarkier tilføjer ofte ikke organisation så meget, som de tilføjer bureaukrati. Det er okay at have kode i kun et toplagsmodul eller klasse i stedet for at opdele på tværs af flere undermoduler eller underklasser. Hvis du laver pakker og moduler, der kræver kode som import spam.eggs.bacon.ham.foo.bar, så gør du din kode for kompliceret.

sparsom er bedre end tæt.

programmører kan ofte lide at proppe så meget funktionalitet i så lidt kode som muligt, såsom one-liners som følgende: 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æsbarhed tæller.

mens strcmp() naturligvis kan betyde “string compare” – funktionen til en person, der har programmeret i C siden 1970 ‘ erne, har moderne computere nok hukommelse til at skrive det fulde funktionsnavn. Slip ikke vokaler fra dine navne eller skriv alt for kortfattet kode. Kode læses oftere, end den er skrevet, så eksplicit, læsbar kode er vigtigere end kortfattet, udokumenteret kode.

særlige tilfælde er ikke specielle nok til at bryde reglerne. Selvom praktisk slår renhed.

disse to aforier, der kommer som et sæt, modsiger hinanden. Programmering er fuld af” bedste praksis”, som programmører skal stræbe efter i deres kode. Fodpaneler denne praksis for en hurtig hack kan være fristende, men kan føre til en rotte reden af inkonsekvent, ulæselig kode. Bøjning bagud for at overholde regler kan dog resultere i meget abstrakt, ulæselig kode. Java-programmeringssprogets forsøg på at tilpasse al kode til dets objektorienterede paradigme resulterer ofte i masser af kedelpladekode til selv det mindste program. At gå linjen mellem disse to aforier bliver lettere med erfaring. Og med tiden lærer du ikke kun reglerne, men lærer også, hvornår du skal bryde dem.

fejl bør aldrig passere lydløst. Medmindre det udtrykkeligt er tavs.

bare fordi programmører ofte ignorerer fejlmeddelelser, betyder det ikke, at programmet skal stoppe med at udsende dem. Lydløse fejl kan opstå, når funktioner returnerer fejlkoder eller None i stedet for at hæve undtagelser. Disse to aforier fortæller os, at det er bedre for et program at fail fast og crash end at tavse fejlen og fortsætte med at køre programmet. De fejl, der uundgåeligt sker senere, vil være sværere at fejle, da de er langt væk fra den oprindelige årsag. Selvom du altid kan vælge at eksplicit ignorere de fejl, dine programmer forårsager, skal du bare være sikker på, at du træffer det bevidste valg at gøre det.

i lyset af tvetydighed nægter fristelsen til at gætte.

computere har gjort mennesker overtroiske: for at uddrive dæmonerne i vores computere udfører vi det hellige ritual om at slukke dem og derefter tænde. Formentlig vil dette løse ethvert mystisk problem. Computere er dog ikke magiske. Hvis din kode ikke fungerer, er der en grund, og kun omhyggelig, kritisk tænkning løser den. Afvis fristelsen til blindt at prøve løsninger, indtil noget ser ud til at fungere; ofte har du blot maskeret problemet snarere end løst det.

der skal være en—og helst kun en—indlysende måde at gøre det på.

dette er en bred side mod Perl programmeringssprogets motto, “Der er mere end en måde at gøre det på!”Det viser sig, at det at have tre eller fire forskellige måder at skrive kode på, der gør det samme, er et dobbeltkantet sværd: du har fleksibilitet i, hvordan du skriver kode, men nu skal du lære alle mulige måder, det kunne have været skrevet for at læse det. Denne fleksibilitet er ikke værd at den 3 eller 4 indsats, der er nødvendig for at lære et programmeringssprog.

selvom den måde måske ikke er indlysende i starten, medmindre du er hollandsk.

denne linje er en vittighed. Guido van Rossum, skaberen og BDFL (Benevolent Dictator for Life) af Python, er hollandsk. Imidlertid forhindrede ikke engang denne aforisme Python i at inkorporere tre forskellige måder at formatere strenge på.

nu er bedre end aldrig. Selvom aldrig er ofte bedre end *lige * nu.

disse to Aforismer fortæller os, at kode, der hænger eller bliver fanget i uendelige sløjfer, naturligvis er værre end kode, der ikke gør det. det er dog næsten helt sikkert bedre at vente på, at dit program er færdigt, end at få det færdigt for tidligt med forkerte resultater.

hvis implementeringen er svær at forklare, er det en dårlig ide. Hvis implementeringen er let at forklare, kan det være en god ide.

Python stræber efter at gøre programmørens job lettere i stedet for at rumme computeren, så et program kører hurtigere. Og programmer skal være forståelige ikke kun af programmøren, der skrev det, men også af andre programmører, der opretholder koden. Disse to aforier minder os om, at hvis “højtydende” kode er så kompliceret, at det er umuligt for programmører at forstå og fejle, så er det dårlig kode. Men desværre, bare fordi det er let at forklare et programs kode til en anden, betyder det ikke, at det ikke er dårlig kode. Programmering er svært.

navnerum er en god ide-lad os gøre flere af dem!

navnerum (og også globale og lokale scopes) er nøglen til at forhindre navne i et modul eller omfang i konflikt med navne i et andet. Men husk også, at flad er bedre end indlejret: så stor som de er, bør navnerum kun laves for at forhindre navnekonflikter og ikke for at tilføje unødvendig kategorisering.

som alle meninger om programmering kan de, jeg har skrevet her, argumenteres imod eller kan simpelthen være irrelevante for din situation. At diskutere, hvordan kode skal skrives, er sjældent så produktiv, som du tror, den er. (Medmindre du skriver en hel bog fuld af programmeringsudtalelser.)