Hvad er Pythons Zen, og hvordan inspirerer det en mulig Zen C

Når vi taler om designfilosofi på sprog programmeringDet er normalt, at følgende dukker op Den velkendte Zen af ​​Pythonden samling af aforismer, der optræder, når man skriver import this i konsollen. Det er dog let at forveksle denne idé med idéen om et formodet "Zen C programmeringssprog" eller med søgen efter et tilsvarende "Zen" inden for selve C-sproget. I praksis har vi en række principper, der har inspireret fællesskaber som Pythons, og som mange udviklere forsøger at ekstrapolere til andre sprog som C, snarere end et nyt sprog kaldet Zen C.

I denne artikel vil vi bruge dette grundlag til at forklare i detaljer, hvad Zen i Python er, hvordan det fungerer, Hvilken filosofi formidler den, og i hvilken grad kan den inspirere en hypotetisk Zen af ​​C?Vi vil undersøge aforismerne én efter én, diskutere praktiske eksempler, nuancer og reelle modsætninger i sprogets udvikling og afslutte med en refleksion over, hvordan disse principper kan anvendes uden for Python-økosystemet.

Hvad Zen egentlig er (og hvorfor det er vigtigt, når vi taler om Zen C)

Den såkaldte Zen af ​​Python, også kendt som PEP 20Det er en samling af aforismer, der indkapsler Tim Peters' vision om, hvordan Python-kodedesign og -skrivning bør være. Selvom mange citerer det, som om det var en slags forfatning, opstod det faktisk som en relativt let tekst med en god portion ironi og et strejf af humor.

Disse aforismer betragtes som en slags manifest for god praksisDette er ikke formelle sprogregler, men de har i høj grad påvirket fællesskabets kultur, skrivningen af ​​PEP'er (Python Enhancement Proposals) og debatter om selve sprogets udvikling: fra introduktionen af ​​"walrus"-operatoren (:=) indtil matchning af strukturelle mønstre.

Når folk taler om "Zen C", spekulerer mange faktisk på, om der findes et tilsvarende sæt principper for C, eller om dette kan tilpasses. filosofi om enkelhed, klarhed og læsbarhed til konteksten af ​​C-sproget, som er på et lavere niveau og mindre "venligt" i sit design end Python.

I praksis, når nogen nævner Zen C, forsøger de normalt at indfange den samme idé: en håndfuld retningslinjer, der hjælper med at skrive klarere og mere vedligeholdelig C-kode, inspireret af, hvad Zen i Python prædiker, selvom Der er ingen officiel PEP 20 til C og heller ikke et magisk modul som f.eks. import this.

Sådan ser Pythons Zen ud i konsollen

En af de mest kendte kuriositeter ved Python er, at du kan vise Zen i enhver interaktiv fortolker ved blot at skrive import thisSiden Python 2.2.1 har fortolkeren indarbejdet modulet this.py som, når den importeres, udskriver aforismerne på engelsk.

Teksten, der vises, er en serie på 19 korte sætninger, der opsummerer Pythons designfilosofi. Det siges, at Peters talte om 20 principper, men Han efterlod kun 19 skrifter, hvilket efterlader det tyvende som en "fantom"-aforisme, som enhver person kan fortolke eller mentalt udfylde.

Internt er modulet this Den gemmer ikke Zen i almindelig tekst, men i en kodet streng med en ROT13 Det er simpelt. Modulet definerer selv en tegnerstatningsordbog og afkoder strengen, før den udskrives. Hvis du inspicerer this.sDu vil se den forvirrede version; hvis du anvender substitutionsalgoritmen, vil du få den læsbare tekst.

Denne brug af ROT13 har en historisk reference: før modulet eksisterede, blev Zen delt på Pythons mailingliste, også forvirret, som en slags Påskeæg til fællesskabetIdeen om at "importere dette" endte endda med at blive et slogan for tidlige økosystemkonferencer, såsom den 10. internationale Python-konference.

De 19 zen-aforismer og deres praktiske betydning

Den originale tekst, på engelsk, begynder med overskriften "The Zen of Python, by Tim Peters" og præsenterer derefter 19 sætninger, som alle Python-brugere har læst på et tidspunkt. Herfra vil vi gennemgå dem en efter en og forklare hvad de indebærer i den daglige kodning, hvordan de normalt fortolkes, og nogle typiske eksempler i Python, der hjælper os med at forestille os, hvordan de kunne oversættes til et "Zen C".

1. Smuk er bedre end grim

Den første regel understreger, at koden ikke kun skal fungere, men også være behagelig at læseSkønhed her handler ikke om udsmykninger, men om klarhed, konsistens og omhyggelig stil: forståelige navne, velplacerede rum og ren struktur.

Et klassisk eksempel i Python er at foretrække menneskeligt læsbare operatorer og nøgleord som and y or vender symboler kryptisk når det er muligt, eller undgå at have flere forskellige operationer stablet op på samme linje ved at ofre læsbarheden for korthedens skyld.

Den samme idé, der anvendes på en hypotetisk Zen C, foreslår at bruge klare indrykningskonventioner, beskrivende navne og opdel komplekse udtryk i flere linjer i stedet for at misbruge makroer eller indviklede udtryk, som kun den person, der skrev dem, forstår.

2. Eksplicit er bedre end implicit

Dette princip understreger, at læseren af ​​koden ikke skal gætte, hvordan noget fungerer. Det er at foretrække, at intentionen er klar. skrevet i fuldt dagslys, selvom det kan involvere et par flere linjer, i stedet for at stole på implicit adfærd eller skjult "magi".

Et meget almindeligt eksempel er at undgå ting som from math import *som bringer alt indholdet af et modul ind i det aktuelle navnerum uden at gøre det klart, hvad der bruges. Det er bedre at skrive from math import sqrt, sin, cos og tydeligt angive, hvad der er behov for.

En anden måde at gøre koden eksplicit på er at introducere mellemliggende variabler med udtryksfulde navne I stedet for at samle operationer i et enkelt udtryk. Det hjælper alle (inklusive dit fremtidige jeg) med at forstå, hvad der foregår, uden at skulle udføre mental reverse engineering.

3. Simpelt er bedre end komplekst

Ideen her er, at når du har muligheden, vælg den simple løsning frem for den kompliceredeDet handler ikke om at undgå al kompleksitet for enhver pris, men om at huske at kode skrives én gang og læses mange gange.

Erfarne programmører insisterer ofte på, at det kræver en indsats at opnå enkelhed: man skal forfine designet, udtrække funktioner, gennemgå navne ... men til gengæld får man Ren og effektiv kode Den er let at forstå og kan vedligeholdes uden frygt. Denne tilgang fungerer for både Python og C: en kort, klar funktion er at foretrække frem for en megafunktion fuld af specialtilfælde og statusflag.

Eksemplerne kontrasterer ofte implementeringer, hvor alt er løst i en enkelt kryptisk linje, med noget længere versioner, men med klare og veldefinerede logiske blokkesom er meget nemmere at forklare.

4. Komplekst er bedre end kompliceret

Sondringen mellem "kompleks" og "kompliceret" er vigtig. Et komplekst system er sammensat af enkle moduler, der kombineresMen hver del, isoleret set, er forståelig. Et kompliceret system er derimod fuldt af skjulte afhængigheder, delte tilstande og logik, der ikke er umiddelbart tydelig.

I kode betyder dette, at man foretrækker designs, hvor hver funktion løser en klar opgave og er afhængig af andre veldefinerede funktioner, i stedet for at samle al logikken ét sted, der bruger globale konstanter, implicitte tilstande og svært følgelige krydsbetingelser.

Ordnet præference opsummeres normalt som Simpelt > Komplekst > KompliceretMed andre ord, hvis det ikke er muligt at være helt enkel, så lad i det mindste kompleksiteten være struktureret og ikke et ulæseligt kaos.

5. Fladt er bedre end indbygget

Dyb indlejring er fjenden af ​​hurtig forståelse. Flere niveauer af ifLøkker inden for løkker og indbyggede strukturer tvinger læseren til at overbelaster dit hoved samtidig. Zen-anbefalingen er at flade ud, når det er rimeligt.

En typisk teknik til at undgå endeløse reder er udtrække dele af koden til små hjælpefunktionereller anvende mere direkte kontrolstrukturer (såsom elif i stedet for else: if ... indlejret). Du kan også bruge generatorer eller rene funktioner, der giver dig mulighed for at behandle samlinger uden løkker inden for løkker.

I Python kan dette involvere at transformere tre indbyggede for-løkker til en række kædede generatorfunktioner; i C, opdel meget dybe funktioner i flere fladere Det reducerer den visuelle og logiske kompleksitet af hvert stykke.

6. Dispergeret er bedre end tæt

Ekstremt kompakt kode kan virke elegant ved første øjekast, men det er ofte en smerte for den, der skal støtte hamZen opfordrer til at give plads til at trække vejret: at adskille logiske blokke i forskellige linjer, indføre mellemrum og linjeskift, når det er nødvendigt.

Et meget illustrativt tilfælde er Inkluder betingelsesord, retursætninger og funktionskald på en enkelt linjeDet er muligt, men omkostningerne ved at forstå det er høje. At opdele den logik i flere linjer med mellemliggende navne gør flowet krystalklart.

I Python anbefales læsbare listeforståelser og korte udtryk; i C gælder det samme for brugen af ​​operatorer, makroer og kædede kald, hvilket er tilrådeligt. udrulle i mellemtrin når de begynder at blive kryptiske.

7. Læsbarhed er vigtig

Udtrykket "Læsbarhed tæller" er nærmest blevet et Python-slogan. Budskabet er ligetil: Koden læses uendeligt flere gange end den skrivesSå den skal optimeres til den person, der læser den, ikke til den person, der skriver den for første gang.

Pythons syntaks blev designet med den prioritet: Obligatorisk indrykning, klare nøgleord og få alternative måder at gøre det samme påI andre sprog, såsom C, afhænger læsbarheden meget mere af teamets stil: brug af navngivningskonventioner, meningsfulde kommentarer, veldefinerede moduler osv.

I begge tilfælde hjælper teknikker som at anvende SOLID-principper, hente inspiration fra "Clean Code"-ideer eller altid bruge navne, der forklarer intentionen, programmet med at være mere bæredygtigt på lang sigt, og at Nye udviklere kan tilmelde sig uden at lide.

8. Særlige tilfælde er ikke så specielle, at de bryder reglerne

Denne aforisme adresserer den tilbagevendende fristelse til at sige: "Denne sag er anderledes; vi gør en undtagelse her." Når man definerer et sæt stil- eller designregler, hvis Enhver særhed bruges som en undskyldning for at springe dem overI sidste ende er reglerne ubrugelige.

Zen foreslår, at selv i "særlige" tilfælde er det bedre at stræbe efter at bevare konsistensenDet betyder at tilpasse designet til det specifikke tilfælde i stedet for at snige en genvej ind, der kompromitterer systemets overordnede klarhed.

Dette princip er især relevant, når man designer API'er, dataformater eller stilretningslinjer i et stort team, hvor enhver undtagelse repræsenterer en udfordring. ekstra kognitiv belastning for alle.

9. Selvom praktisk sans vinder over renhed

Disse to aforismer (regler og praktisk anvendelighed) opvejer hinanden. På den ene side kræves der konsistens; på den anden side anerkendes det, at i det virkelige liv Vi kan ikke altid være fuldstændig "rene" I design er pragmatiske genveje nogle gange nødvendige for at overholde deadlines, tilpasse sig miljømæssige begrænsninger eller fremme implementeringen af ​​en løsning.

Nøglen er ikke at lade sig rive med: praktiske hensyn kan retfærdiggøre pragmatiske genveje til at overholde deadlinesMen det bør ikke blive en undskyldning for at acceptere sjusket arbejde. Et typisk eksempel i Python er brugen af ​​præcise konstruktioner, når de rent faktisk forbedrer koden, uden at ty til den "sorte magi", der skal tydes.

I en hypotetisk Zen C ville dette ses i beslutninger som f.eks. acceptere bestemt brug af makroer eller specifikke optimeringer compiler, når de rent faktisk forbedrer ydeevnen uden at gøre koden uforståelig.

10. Fejl bør aldrig ignoreres.

Denne retningslinje omhandler håndtering af undtagelser og fejl. Blokkonstruktioner try/except helt generisk, der simpelthen gør det pass De er en sikker opskrift på vanskelige problemer: noget går galt, ingen bemærker det, og tilsyneladende tilfældig adfærd opstår måneder senere.

Zen anbefaler, at fejl, undtagen i tilfælde af meget bevidste beslutninger, skal gøres synlige: at kun de tilsigtede typer registreres, at de registreres i logsDet sende klare beskeder eller endda stoppe udførelsen, hvis systemet ikke ved, hvordan det skal gendannes.

I C, systematisk ignorering af returkoder eller manglende kontrol af nullpointere Det er en garanteret måde at forvandle vedligeholdelse til et mareridt.

11. Medmindre de udtrykkeligt er blevet tavse

Som med andre regler spiller nuancer en rolle her. Der er situationer, hvor du kender til en specifik fejl, du har studeret dens konsekvenser, og du beslutter dig for, at Det er ikke kritisk, eller at du har en kontrolleret måde at handle påI disse tilfælde kan det være rimeligt eksplicit at bringe ham til tavshed.

Et typisk eksempel ville være fange en ValueError specifikt og skriv en fejlfindingsmeddelelse, der angiver, at den er håndteret korrektuden at udvide undtagelsen yderligere. Nøglen er dog, at det er en bevidst og dokumenteret beslutning, ikke en måde at dække over problemer på.

I C ville det tilsvarende være håndter en kendt fejlkode ved at returnere en dokumenteret standardværdi, registrere hændelsen, hvis det er relevant, og kun i den kontekst ignorere fejlen uden at applikationen går ned.

12. Når du står over for tvetydighed, så afvis fristelsen til at gætte.

Denne aforisme fremhæver en meget almindelig fælde: mentalt at udfylde hullerne, når kravene, designet eller endda selve koden er uklare. Zen-fortalere Opfind ikke betydninger, hvor der ingen er.Hvis noget er tvetydigt, er det bedst at fremtvinge en eksplicit beslutning.

I kode oversættes det til funktionsnavne, der forklarer præcis, hvad de gør, kommentarer, der præciserer vigtige antagelser, og vigtigst af alt, tests, der definerer den forventede adfærdHvis det ikke vides, hvad der skal ske, vil koden ende med at "gætte" og vil næsten helt sikkert være forkert.

Når dette princip anvendes på en potentiel Zen C, bliver det en konstant påmindelse: Gå ikke ud fra, at compileren, platformen eller standardbiblioteket vil gøre det, du forventer. uden at have verificeret det i dokumentationen eller i konkrete tests.

13. Der burde kun være én åbenlys måde at gøre det på

Dette princip er næsten kernen i Pythons identitet. I modsætning til mottoer som Perls ("Der er mere end én måde at gøre det på"), stræber Python efter at sikre, at for en given opgave, der er en klart foretrukken vejDette forenkler læring og gør kode fra forskellige personer mere ensartet.

Et klassisk eksempel er iteration over sekvenser. I Python promoveres en meget specifik tilgang: for elemento in secuencia:I stedet for at tvinge manuel indeksering frem, undtagen når det er nødvendigt, gør dette læseløkker næsten trivielle.

For C kunne denne ånd omsættes til at indføre, på teamniveau, Standardmønstre for tilbagevendende operationeren almindelig måde at navigere i arrays, administrere hukommelse eller håndtere fejl på, i stedet for at hver udvikler opfinder sin egen stil.

14. Selvom den metode måske ikke virker indlysende i starten (medmindre du er hollænder)

Denne aforisme tilføjer et glimt: den foretrukne måde er ikke altid indlysende i starten. Ofte kræver det at blive fortrolig med sproget, dets biblioteker og dets økosystem, før den "indlysende måde" begynder at føles naturlig.

Nævnelsen af ​​hollænderne er en direkte henvisning til Guido van Rossum, skaberen af ​​Python, som er hollandsk. For ham kan mange designbeslutninger være intuitive, fordi han ved præcis, hvad han havde til hensigt; for resten kræver det mere erfaring. en periode med tilpasning og læring.

Noget lignende ville ske i ethvert uformelt "Zen C": Det, der virker indlysende for sprogveteraner (hvordan man bruger pointere, hvordan man organiserer overskrifter, hvordan man strukturerer et projekt), kan være meget uklart for en person, der er ny inden for emnet.

15. Nu er bedre end nogensinde, selvom aldrig ofte er bedre end lige nu.

Disse to aforismer taler om prioriteter og timing. På den ene side opfordrer de os til ikke at falde i analyselammelse: Det er bedre at gøre rimelige fremskridt end ingenting. At vente på et perfekt design, der aldrig kommer. På den anden side tjener det som en påmindelse om, at det at forhaste sig med at ændre ting uden at tænke sig om kan skabe endnu værre problemer.

I kode oversættes det til At finde balancen mellem at gå i gang med arbejdet og ikke improvisere strukturelle ændringer uden at tænke over det.At udsætte visse kritiske opgaver på ubestemt tid er normalt en dårlig idé, men det hjælper heller ikke konstant at afbryde det, du laver, for at jagte hver ny idé.

Den ideelle tilgang er normalt at behandle systemets udvikling som en iterativ proces: introducer målte ændringer og evaluer deres effektForfin ... og vedligehold en tydelig to-do-liste, så vigtige problemer ikke bliver liggende "for evigt".

16. Hvis implementeringen er svær at forklare, er det en dårlig idé.

Hvis du har brug for et indviklet afsnit til at forklare, hvordan et stykke kode fungerer, er problemet sandsynligvis ikke dine kommunikationsevner, men selve designet. Denne aforisme opfordrer til at bruge forklaring som design sundhedstest.

Når en implementering er så kompleks, at den er vanskelig at forklare på en enkel måde, betyder det normalt, at der er for mange blandede ansvarsområderDårligt definerede afhængigheder eller uraffinerede beslutninger er et tegn på, at refactoring er tilrådeligt, før man accepterer denne tilgang.

Dette kriterium er meget nyttigt i både Python og C: Hvis du ikke kan forklare i et par sætninger, hvad en funktion eller et modul gørNormalt er der plads til strukturelle forbedringer.

17. Hvis implementeringen er let at forklare, kan det være en god idé

Bagsiden af ​​det foregående punkt er, at når du kan beskrive en løsning på en klar, præcis og ligetil måde, er du sandsynligvis på rette spor. Det garanterer ikke, at ideen er perfekt, men det er et godt tegn på, at du er på rette spor. kompleksiteten er under kontrol.

Dette princip forbinder sig rigtig godt med praksisser som "gummiandteknikken": at forklare højt, hvad din kode gør ved en anden person (eller et livløst objekt), hjælper med at opdage uoverensstemmelser og bekræfte, når noget er velgennemtænkt.

I en teamkontekst er det meget nemmere at gennemgå, vedligeholde og udvikle den del af systemet, hvis et teammedlem hurtigt kan forstå, hvad et stykke kode gør efter en kort forklaring.

18. Navnerum er en god idé: lad os lave flere af dem

Den sidste aforisme fremhæver vigtigheden af ​​navnerum som et værktøj til at organisere kode og undgå kollisioner. I Python tilbyder moduler, pakker, klasser og funktioner forskellige niveauer af organisation. indkapsling og ansvarsadskillelse.

Konsekvent brug af navnerum gør det muligt for identifikatorer med samme navn at eksistere i forskellige kontekster uden konflikter og hjælper med at gruppere relaterede elementer under en enkelt logisk paraply. Udvidelse af brugen af ​​disse mekanismer fører ofte til mere modulære arkitekturer.

I C, hvor navnerumssystemet er langt mere rudimentært, omsættes denne idé til navngivningskonventioner, strukturering efter header- og kildefiler og disciplineret brug af static og præfikser for at undgå kollisioner. En fornuftig "Zen C" ville invitere behandle hvert modul som et lille, veldefineret navnerum.

Oversættelser til spansk og kulturelle nuancer

Gennem årene er der blevet foreslået adskillige oversættelser af disse aforismer til spansk. Nogle vælger "Smuk er bedre end grim", andre "Smuk er bedre end grim" osv. Alle søger at bevare originalens ånd, selvom der uundgåeligt opstår nogle variationer. nuancer i stil og valg af ordforråd oversætterens karakteristika.

På spansk fra Spanien er det almindeligt at tale om kode som "pæn", "læselig" eller "klar", og om undgå "fejl" eller "hurtige lapper"Den samme idé ligger til grund for den originale Zen, som blander en seriøs tone med et strejf af humor, især i aforismen, der nævner, at den indlysende måde måske ikke er det i første omgang, "medmindre du er hollænder".

Disse oversættelser tjener også til at gøre teksten mere tilgængelig for personer, der ikke taler flydende engelsk, uden at man glemmer, at principperne er anvendelige. til ethvert sprog og ethvert udviklingsfællesskabud over Python-økosystemet.

Er Pythons Zen en joke eller en hellig regel?

Inden for Python-fællesskabet er der en del debat om Zens præcise status. På den ene side nævner mange formelle dokumenter (PEP'er) det som motivation eller begrundelse af beslutninger, og i mailinglister over nøgleudviklere bruges det som et argument for eller imod specifikke forslag.

På den anden side har nogle vedligeholdelsesudbydere påpeget, at at bruge en zen-frase som et våben ("Dette krænker zen, derfor er det dårligt") giver ikke altid mening. Der er endda PEP'er, der kommenterer, at visse aforismer engang blev fortolket som kritik af selve sproget i dets begyndelse og ikke bør tages bogstaveligt.

Realiteten er, at Zen fungerer bedst som kulturelt kompas og inspirationskilde hvilket som en streng designregel. Python, med El tiempoDen har inkorporeret funktioner (såsom tildeling i udtryk eller mønstermatchning), som nogle anser for at være mere "komplekse" eller mindre i overensstemmelse med den oprindelige enkelhed, og alligevel er de blevet taget i brug for deres anvendelighed.

I den forstand ville det at tænke på en "Zen C" have mere at gøre med indfang generelle principper der hjælper med at skrive bedre C-kode, uden at det er meningen, at de skal blive ufleksible love, der blokerer enhver udvikling af stil eller værktøjer.

Denne samling af aforismer, oversættelser, eksempler og diskussioner danner en slags mindmap over, hvordan vi forstår "god kode": læsbar, så enkel som muligt, eksplicit i sine intentioner og gennemtænkt struktureret. Uanset om det er i Python, C eller et hvilket som helst andet sprog, At anvende den filosofi gør ofte forskellen på et program, der er en kamp, ​​og et, der er behageligt at arbejde med..