Invent with Python Blog

Zen Av Python Av Tim Peters er 20 retningslinjer for utformingen Av Python-språket. Python-koden din trenger ikke nødvendigvis å følge disse retningslinjene, men de er gode å huske på. Zen Av Python er Et Påskeegg, eller skjult spøk, som vises hvis du kjører 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!

MERK: Mystisk er bare 19 av retningslinjene skrevet ned. Guido van Rosum velig sa at den manglende 20. aforisme er » noen bisarre Tim Peters in-spøk.»

til slutt er disse retningslinjene meninger som kan argumenteres for eller imot. Som alle gode sett med moralske koder, motsier de seg noen ganger for å gi mest fleksibilitet. Her er min egen tolkning av disse aforismene:

Vakker er bedre enn stygg.

Programmerere skriver ofte kode raskt uten bekymring for lesbarhet. Selv om koden ikke trenger å være lesbar, må koden til Python-språket selv være gjennomtenkt, konsistent og en glede å bruke. Selvfølgelig må ikke alle skript være vakre, og skjønnhet er subjektiv, men mye Av Pythons popularitet er et resultat av å være så lett å jobbe med.

Eksplisitt er bedre enn implisitt.

«Denne aforismen er selvforklarende», det ville være en forferdelig forklaring på enhver aforisme. På samme måte er det bedre for kode å være verbose og eksplisitt. Du bør unngå å skjule kodens funksjonalitet bak obskure språkfunksjoner som krever kjennskap til å forstå fullt ut.

Enkel er bedre enn kompleks. Kompleks er bedre enn komplisert.

disse to aforismene minner oss om at å bygge noe kan gjøres ved hjelp av enkle eller komplekse teknikker. Med et enkelt problem, for eksempel å bygge et fuglhus, er en enkel løsning bedre. Å bygge en diesel togmotor, derimot, er et komplekst problem som krever komplekse teknikker. Selv om du teknisk kunne lage en diesel togmotor ved hjelp av birdhouse teknikker, vil du sannsynligvis ende opp med et komplisert, Rube Goldberg arrangement av birdhouse deler som ikke ville være en ideell løsning. Foretrekker enkelhet til kompleksitet, men vet grensene for enkelhet.

Flat er bedre enn nestet.

Programmerere elsker å organisere ting i kategorier, spesielt kategorier som inneholder underkategorier som inneholder andre underkategorier. Disse hierarkiene legger ofte ikke til organisasjon så mye som de legger til byråkrati. Det er greit å ha kode i bare en topplagsmodul eller klasse i stedet for å dele opp over flere undermoduler eller underklasser. Hvis du lager pakker og moduler som krever kode som import spam.eggs.bacon.ham.foo.bar, gjør du koden din for komplisert.

Sparsom er bedre enn tett.

Programmerere liker ofte å stappe så mye funksjonalitet i så lite kode som mulig, for eksempel 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.

Lesbarhet teller.

mens strcmp() åpenbart kan bety» string compare » – funksjonen til noen som har programmert I C siden 1970-tallet, har moderne datamaskiner nok minne til å skrive ut hele funksjonsnavnet. Ikke slipp vokaler fra navnene dine eller skriv altfor tett kode. Kode leses oftere enn det er skrevet, så eksplisitt, lesbar kode er viktigere enn avvisende, udokumentert kode.

Spesielle tilfeller er ikke spesielle nok til å bryte reglene. Selv om praktisk slår renhet.

Disse to aforismene, som kommer som et sett, motsier hverandre. Programmering er full av «beste praksis» som programmerere bør streve for i koden sin. Skørt disse praksisene for en rask hack kan være fristende, men kan føre til en rottereir av inkonsekvent, ulæselig kode. Men å bøye seg bakover for å overholde regler kan resultere i svært abstrakt, uleselig kode. Java programmeringsspråkets forsøk på å passe all kode til sitt objektorienterte paradigme resulterer ofte i mye standardkode for selv det minste programmet. Å gå linjen mellom disse to avorismene blir lettere med erfaring. Og med tiden vil du ikke bare lære reglene, men også lære når du skal bryte dem.

Feil bør aldri passere stille. Med mindre det er eksplisitt stilnet.

Bare fordi programmerere ofte ignorerer feilmeldinger betyr ikke at programmet skal slutte å sende dem. Stille feil kan skje når funksjoner returnerer feilkoder eller None i stedet for å heve unntak. Disse to aforismene forteller oss at det er bedre for et program å fail fast og krasje enn å stille feilen og fortsette å kjøre programmet. Feilene som uunngåelig skjer senere, vil være vanskeligere å feilsøke siden de er langt fjernet fra den opprinnelige årsaken. Selv om du alltid kan velge å eksplisitt ignorere feilene dine programmer forårsaker, bare vær sikker på at du gjør det bevisste valget om å gjøre det.

i møte med tvetydighet, nekter fristelsen til å gjette.

Datamaskiner har gjort mennesker overtroiske: for å utøve demonene i våre datamaskiner utfører vi det hellige ritualet om å slå dem av og deretter på. Tilsynelatende vil dette løse et mystisk problem. Datamaskiner er imidlertid ikke magiske. Hvis koden din ikke fungerer, er det en grunn og bare forsiktig, kritisk tenkning vil løse det. Avvis fristelsen til blindt å prøve løsninger til noe ser ut til å fungere; ofte har du bare maskert problemet i stedet for løst det.

Det bør være en—og helst bare en-åpenbar måte å gjøre det på.

Dette er en bredside mot Perl programmeringsspråk motto, » Det er mer enn en måte å gjøre det!»Det viser seg at å ha tre eller fire forskjellige måter å skrive kode på som gjør det samme, er et dobbeltkantet sverd: du har fleksibilitet i hvordan du skriver kode, men nå må du lære alle mulige måter det kunne vært skrevet for å lese det. Denne fleksibiliteten er ikke verdt 3x eller 4x innsatsen som trengs for å lære et programmeringsspråk.

selv om den måten kanskje ikke er åpenbar først, med mindre du er nederlandsk.

denne linjen er en vits. Guido van Rossum, Skaperen Og Bdfl (Velvillig Diktator For Livet) Av Python, er nederlandsk. Men ikke engang denne aforismen forhindret Python i å inkorporere tre forskjellige måter å formatere strenger på.

Nå er bedre enn aldri. Selv om aldri er ofte bedre enn * høyre * nå.

disse to aforismene forteller oss at kode som henger eller blir fanget i uendelige løkker, er åpenbart verre enn kode som ikke gjør det. det er imidlertid nesten sikkert bedre å vente på at programmet skal fullføres enn å få det ferdig for tidlig med feil resultater.

hvis implementeringen er vanskelig å forklare, er det en dårlig ide. Hvis implementeringen er lett å forklare, kan det være en god ide.

Python forsøker å gjøre programmererens jobb enklere enn å imøtekomme datamaskinen, slik at et program kjører raskere. Og programmer må være forståelige, ikke bare av programmereren som skrev den, men også av andre programmerere som opprettholder koden. Disse to avorismene minner oss om at hvis» høy ytelse » -kode er så komplisert at det er umulig for programmerere å forstå og feilsøke, så er det dårlig kode. Men dessverre, bare fordi det er lett å forklare et programs kode til noen andre, betyr det ikke at det ikke er dårlig kode. Programmering er vanskelig.

Navnerom er en honking god ide-la oss gjøre flere av dem!

Navnerom (og også globale og lokale områder) er nøkkelen for å hindre at navn i en modul eller område kommer i konflikt med navn i en annen. Men husk også at flat er bedre enn nestet: så stor som de er, navnerom bør gjøres bare for å hindre navnekonflikter, og ikke å legge unødvendig kategorisering.

som alle meninger om programmering, kan de jeg har skrevet her argumenteres mot eller kan bare være irrelevante for situasjonen din. Å argumentere for hvordan kode skal skrives, er sjelden så produktiv som du tror det er. (Med mindre du skriver en hel bok full av programmerings meninger.)