Kaj je zen Pythona in kako navdihuje morebitnega zen C-ja

Ko govorimo o filozofiji oblikovanja v jezikih programiranjeObičajno se pojavi naslednje Znani Zen Pythona: tista zbirka aforizmov, ki se pojavi pri pisanju import this v konzoli. Vendar pa je to idejo enostavno zamenjati z idejo domnevnega "programskega jezika Zen C" ali z iskanjem enakovrednega "Zen" znotraj samega jezika C. V praksi imamo vrsto načel, ki so navdihnila skupnosti, kot je Python, in ki jih mnogi razvijalci poskušajo ekstrapolirati na druge jezike, kot je C, namesto novega jezika, imenovanega Zen C.

V tem članku bomo na podlagi tega podrobno razložili, kaj je zen Pythona, kako deluje, kakšno filozofijo sporoča in v kolikšni meri lahko navdihne hipotetični zen C-ja. Aforizme bomo preučili enega za drugim, razpravljali o praktičnih primerih, niansah in resničnih protislovjih pri razvoju jezikov, zaključili pa bomo z razmislekom o tem, kako je mogoče ta načela uporabiti zunaj ekosistema Pythona.

Kaj Zen v resnici je (in zakaj je pomemben, ko govorimo o Zen C)

Tako imenovani Zen of Python, znan tudi kot PEP 20 , je zbirka aforizmov, ki povzemajo vizijo Tima Petersa o tem, kako je treba pristopiti k načrtovanju in pisanju kode v Pythonu. Čeprav ga mnogi navajajo, kot da bi bil nekakšna ustava, je v resnici nastal kot relativno lahkotno besedilo z dokajšnjo mero ironije in kančkom humorja.

Ti aforizmi veljajo za neke vrste manifest dobrih praksTo niso formalna pravila jezika, vendar so močno vplivala na kulturo skupnosti, pisanje predlogov za izboljšave Pythona (PEP) in razprave o samem razvoju jezika: od uvedbe operatorja »mrož« (:=) dokler se strukturni vzorci ne ujemajo.

Ko ljudje govorijo o »zenovskem C-ju«, se mnogi dejansko sprašujejo, ali obstaja enakovreden nabor načel za C oziroma ali je to filozofijo preprostosti, jasnosti in berljivosti mogoče prilagoditi kontekstu jezika C, ki je nižje ravni in manj »prijazen« v svoji zasnovi kot Python.

V praksi, ko nekdo omeni Zen C, običajno poskuša ujeti isto idejo: peščico smernic, ki pomagajo pisati jasnejšo in bolj vzdržno kodo C, navdihnjeno s tem, kar pridiga Zen Pythona, čeprav Ni uradnega PEP 20 za C niti čarobnega modula, kot je import this.

Kako izgleda Pythonov Zen v konzoli

Ena najbolj znanih zanimivosti Pythona je, da lahko Zen prikažete v katerem koli interaktivnem interpreterju s preprostim tipkanjem import thisOd različice Pythona 2.2.1 naprej ima interpreter vključen modul this.py ki ob uvozu natisne aforizme v angleščini.

Besedilo, ki se prikaže, je niz 19 kratkih stavkov, ki povzemajo Pythonovo oblikovalsko filozofijo. Pravijo, da je Peters govoril o 20 načelih, a jih je zapisal le 19 , dvajseto pa je pustil kot "fantomski" aforizem, ki ga lahko vsakdo interpretira ali miselno dopolni.

V notranjosti modul this Ne shranjuje Zen v navadnem besedilu, temveč v kodiranem nizu z ROT13 Preprosto. Modul sam definira slovar za zamenjavo znakov in dekodira niz, preden ga izpiše. Če pregledate this.sVideli boste zakrito različico; če uporabite algoritem zamenjave, boste dobili berljivo besedilo.

Ta uporaba ROT13 ima zgodovinski pomen: preden je modul obstajal, je bil Zen deljen na poštnem seznamu Python, prav tako zakrit, kot nekakšno velikonočno jajce za skupnost . Ideja o »uvozu tega« je celo postala slogan za zgodnje konference o ekosistemih, kot je bila 10. mednarodna konferenca o Pythonu.

19 zen aforizmov in njihov praktični pomen

Izvirno besedilo v angleščini se začne z naslovom »Zen Pythona, avtor Tim Peters« in nato predstavlja 19 stavkov, ki jih je vsak programer v Pythonu že kdaj prebral. Od tu naprej jih bomo pregledali enega za drugim, razložili njihov pomen v vsakdanjem kodiranju , kako se običajno interpretirajo, in predstavili tipičen primer v Pythonu, ki nam bo pomagal vizualizirati, kako bi jih lahko prevedli v pristop »Zen C«.

1. Lepo je boljše kot grdo

Prvo pravilo poudarja, da koda ne sme le delovati, ampak mora biti tudi prijetna za branje . Lepota tukaj ni v okraskih, temveč v jasnosti, doslednosti in skrbnem slogu: razumljiva imena, dobro postavljeni presledki in čista struktura.

Klasični primer v Pythonu je dajanje prednosti človeku berljivim operatorjem in ključnim besedam, kot je and y or pred simboli kriptično, kadar je na voljo, ali pa se izognite kopičenju več različnih operacij v isti vrstici tako, da žrtvujete berljivost zaradi kratkosti.

Ista ideja, uporabljena za hipotetični Zen C, bi predlagala uporabo jasnih konvencij zamikanja, opisnih imen in ločevanje kompleksnih izrazov v več vrstic, namesto zlorabe makrov ali zapletenih izrazov, ki jih razume le oseba, ki jih je napisala.

2. Eksplicitno je boljše od implicitnega

To načelo poudarja, da bralcu kode ni treba ugibati, kako nekaj deluje. Bolje je, da je namen eksplicitno naveden , tudi če to zahteva nekaj dodatnih vrstic kode, kot pa da se zanašamo na implicitno vedenje ali skrito "magijo".

Zelo pogost primer je izogibanje stvarem, kot so from math import *ki prenesejo vso vsebino modula v trenutni imenski prostor, ne da bi bilo jasno, kaj se uporablja. Bolje je napisati from math import sqrt, sin, cos in izrecno navesti, kaj je potrebno.

Drug način za eksplicitno opredelitev kode je uvedba vmesnih spremenljivk z izraznimi imeni namesto kopičenja operacij v en sam izraz. To pomaga vsakomur (vključno z vašim bodočim jazom) razumeti, kaj se dogaja, ne da bi moral izvajati miselni obratni inženiring.

3. Preprosto je boljše od zapletenega

Ideja je, da bi morali, ko imate možnost izbire, izbrati preprosto rešitev namesto zapletene . Ne gre za to, da se za vsako ceno izognemo vsej kompleksnosti, temveč za to, da si zapomnimo, da je koda napisana enkrat in prebrana večkrat.

Izkušeni programerji pogosto poudarjajo, da doseganje preprostosti zahteva trud: izpopolnjevanje zasnove, izločanje funkcij, pregled imen ... v zameno pa dobite čisto, učinkovito kodo , ki jo je enostavno razumeti in vzdrževati. Ta pristop velja tako za Python kot za C: kratka, jasna funkcija je boljša od mega funkcije, polne posebnih primerov in statusnih zastavic.

Primeri pogosto primerjajo implementacije, kjer je vse rešeno v eni sami kriptični vrstici, z nekoliko daljšimi različicami, vendar z jasnimi in dobro definiranimi logičnimi bloki , ki jih je veliko lažje razložiti.

4. Kompleksno je boljše od zapletenega

Razlika med "kompleksnim" in "zapletenim" je pomembna. Kompleksen sistem je sestavljen iz preprostih modulov, ki združujejo , vendar je vsak del, obravnavan ločeno, razumljiv. Zapleten sistem pa je poln skritih odvisnosti, skupnih stanj in logike, ki ni takoj očitna.

V kodi to pomeni, da dajemo prednost zasnovam, kjer vsaka funkcija rešuje jasno nalogo in se zanaša na druge dobro definirane funkcije, namesto da bi vso logiko zbrali na enem mestu, ki uporablja globalne konstante, implicitna stanja in težko sledljive navzkrižne pogoje.

Urejena preferenca je običajno povzeta kot Preprosto > Kompleksno > Zapleteno . To pomeni, da če ni mogoče biti popolnoma preprost, mora biti vsaj kompleksnost strukturirana in ne neberljiv kaos.

5. Ploščato je boljše od vgnezdenega

Globoko gnezdenje je sovražnik hitrega razumevanja. Več ravni ifZanke znotraj zank in vgnezdene strukture silijo bralca, da preobremenitev glave hkrati. Zen priporoča sploščitev, kadar koli je to razumno.

Tipična tehnika za izogibanje neskončnim gnezdom je izvleči dele kode v majhne pomožne funkcijeali pa uporabite bolj neposredne nadzorne strukture (kot so elif namesto else: if ... (gnezdeno). Uporabite lahko tudi generatorje ali čiste funkcije, ki omogočajo obdelavo zbirk brez zank znotraj zank.

V Pythonu bi to lahko vključevalo pretvorbo treh vgnezdenih zank for v niz verižnih generatorskih funkcij; v C-ju segmentacija zelo globokih funkcij v več bolj ravnih funkcij zmanjša vizualno in logično kompleksnost vsakega dela.

6. Razpršeno je boljše kot gosto

Izjemno kompaktna koda se na prvi pogled morda zdi elegantna, vendar je pogosto muka za osebo, ki jo mora vzdrževati . Zen spodbuja puščanje odprtin: ločevanje logičnih blokov na različne vrstice ter uvajanje presledkov in prelomov vrstic, kadar je to potrebno.

Zelo ilustrativen primer je vstavljanje pogojnih izrazov, stavkov return in klicev funkcij v eno samo vrstico . Možno je, vendar so stroški za razumevanje visoki. Če to logiko razdelimo v več vrstic z vmesnimi imeni, je potek kristalno jasen.

V Pythonu so priporočljivi berljivi seznami in kratki izrazi; v C-ju velja enako za uporabo operatorjev, makrov in verižnih klicev, ki jih je treba uvesti v vmesnih korakih , ko postanejo nerazumljivi.

7. Berljivost je pomembna

Stavek »Berljivost šteje« je postal skoraj slogan Pythona. Sporočilo je preprosto: koda se bere veliko pogosteje, kot se piše , zato jo je treba optimizirati za bralca, ne za osebo, ki jo tipka prvič.

Pythonova sintaksa je bila zasnovana s to prednostno nalogo: obvezno zamikanje, jasne ključne besede in malo alternativnih načinov za dosego istega rezultata . V drugih jezikih, kot je C, je berljivost veliko bolj odvisna od sloga ekipe: uporaba konvencij poimenovanja, smiselni komentarji, dobro definirani moduli in tako naprej.

V obeh primerih tehnike, kot so uporaba načel SOLID, črpanje navdiha iz idej »čiste kode« ali nenehno iskanje imen, ki pojasnjujejo namen, pomagajo programu, da je dolgoročno bolj trajnosten, in omogočajo novim razvijalcem, da se brez težav pridružijo.

8. Posebni primeri niso tako posebni, da bi kršili pravila

Ta aforizem izziva ponavljajočo se skušnjavo, da bi rekli: »Ta primer je drugačen; tukaj bomo naredili izjemo.« Ko je določen niz slogovnih ali oblikovalskih pravil in se vsaka nenavadnost uporabi kot izgovor za njihovo kršenje , pravila na koncu postanejo nesmiselna.

Zen predlaga, da si je tudi v »posebnih« primerih bolje prizadevati za doslednost . To pomeni prilagoditev zasnove posameznemu primeru, namesto da bi se lotevali rešitev, ki bi ogrozila splošno jasnost sistema.

To načelo je še posebej pomembno pri oblikovanju API-jev, podatkovnih formatov ali slogovnih smernic v veliki ekipi, kjer vsaka izjema doda dodatno kognitivno obremenitev za vse.

9. Čeprav praktičnost zmaga nad čistostjo

Ta dva aforizma (pravila in praktičnost) se medsebojno uravnotežujeta. Po eni strani se zahteva doslednost, po drugi strani pa se priznava, da v resničnem življenju ne moremo biti vedno popolnoma »čisti« pri oblikovanju. Včasih moramo izbrati pragmatične bližnjice, da bi izpolnili roke, se prilagodili okoljskim omejitvam ali olajšali sprejetje rešitve.

Ključno je imeti stvari pod nadzorom: praktičnost lahko upraviči pragmatične bližnjice za doseganje rokov , vendar ne sme postati izgovor za sprejemanje kakršnega koli površnega dela. Tipičen primer v Pythonu je uporaba jedrnatih konstruktov, ko resnično izboljšajo kodo, ne da bi se zatekli k tisti "črni magiji", ki jo je treba dešifrirati.

V hipotetičnem Zen C-ju bi se to pokazalo v odločitvah, kot je sprejemanje določenih uporab makrov ali optimizacij, specifičnih za prevajalnik, kadar dejansko izboljšajo delovanje, ne da bi koda postala nerazumljiva.

10. Napak se nikoli ne sme ignorirati.

Ta smernica obravnava obravnavo izjem in napak. Blokovne konstrukcije try/except popolnoma generično, kar preprosto počne pass So zanesljiv recept za težave, ki jih je težko odpraviti: nekaj gre narobe, nihče ne opazi in na videz naključno vedenje se pojavi mesece kasneje.

Zen priporoča, da so napake, razen v primerih zelo premišljene odločitve, vidne: da se zajamejo le pričakovane vrste, da se zabeležijo v dnevnike , da oddajajo jasna sporočila ali da se izvajanje celo ustavi, če sistem ne ve, kako si opomore.

V jeziku C sistematično ignoriranje povratnih kod ali nepreverjanje ničelnih kazalcev zagotovo spremeni vzdrževanje v nočno moro.

11. Razen če so bili izrecno utišani

Kot pri drugih pravilih tudi tukaj pridejo v poštev nianse. Obstajajo situacije, ko se zavedate določene napake, preučite njene posledice in se odločite, da ni kritična ali da imate nadzorovan način za njeno reševanje . V takih primerih je lahko smiselno, da o njej izrecno molčite.

Tipičen primer bi bil zajem ValueError posebej in napišite sporočilo o odpravljanju napak, ki navaja, da je bilo pravilno obravnavanobrez nadaljnjega razširjanja izjeme. Vendar je ključno, da gre za zavestno in dokumentirano odločitev, ne pa za način prikrivanja težav.

V jeziku C bi bilo enakovredno obravnavati znano kodo napake z vrnitvijo dokumentirane privzete vrednosti , po potrebi zabeležiti dogodek in le v tem kontekstu ignorirati napako, ne da bi se aplikacija zrušila.

12. Ko se soočite z dvoumnostjo, zavrnite skušnjavo ugibanja.

Ta aforizem izpostavlja zelo pogosto past: miselno zapolnjevanje vrzeli, ko zahteve, zasnova ali celo sama koda niso jasni. Zen se zavzema proti izmišljanju pomenov tam, kjer jih ni ; če je nekaj dvoumno, je najbolje vsiliti eksplicitno odločitev.

V kodi se to prevede v imena funkcij, ki natančno pojasnjujejo, kaj počnejo, komentarje, ki pojasnjujejo pomembne predpostavke, in, kar je najpomembneje, teste, ki določajo pričakovano vedenje . Če ne veste, kaj bi se moralo zgoditi, bo koda na koncu "ugibala" in bo skoraj zagotovo napačna.

Ko se to načelo uporabi za potencialni Zen C, postane stalen opomin: ne predvidevajte, da bo prevajalnik, platforma ali standardna knjižnica naredila tisto, kar si zamislite, ne da bi to preverili v dokumentaciji ali v konkretnih testih.

13. Obstajati mora samo en očiten način za to

To načelo je skoraj v samem srcu identitete Pythona. V nasprotju z gesli, kot je Perlovo ("Obstaja več kot en način za to"), si Python prizadeva zagotoviti, da za dano nalogo obstaja jasno prednostna pot . To poenostavi učenje in naredi kodo različnih ljudi bolj dosledno.

Klasični primer je iteracija po zaporedjih. V Pythonu se promovira zelo specifičen pristop: for elemento in secuencia:Namesto vsiljevanja ročnega indeksiranja, razen kadar je to potrebno, to naredi bralne zanke skoraj nepomembne.

Pri jeziku C bi se ta duh lahko prevedel v sprejetje standardnih vzorcev za ponavljajoče se operacije na ravni ekipe : skupni način premikanja po matrikah, upravljanja pomnilnika ali obravnavanja napak, namesto da bi si vsak razvijalec izmislil svoj slog.

14. Čeprav se ta metoda sprva morda ne zdi očitna (razen če ste Nizozemec)

Ta aforizem doda še en pomežik: želeni način ni vedno očiten na začetku. Pogosto se je treba seznaniti z jezikom, njegovimi knjižnicami in ekosistemom, da se ta "očiten način" začne zdeti naraven.

Omemba Nizozemcev je neposredna referenca na Guida van Rossuma, ustvarjalca Pythona, ki je Nizozemec. Zanj so lahko številne oblikovalske odločitve intuitivne, ker točno ve, kaj je nameraval; za ostalo je potrebno obdobje prilagajanja in učenja.

Nekaj ​​podobnega bi se zgodilo v katerem koli neformalnem "zenovskem C-ju": kar se jezikovnim veteranom zdi očitno (kako uporabljati kazalce, kako organizirati glave, kako strukturirati projekt), je lahko zelo nejasno nekomu, ki je na tem področju nov.

15. Zdaj je bolje kot kdaj koli prej, čeprav nikoli ni pogosto bolje kot zdaj.

Ta dva aforizma govorita o prioritetah in času. Po eni strani nas spodbujata, da ne zapademo v paralizo analize: bolje je razumno napredovati, kot pa ničesar storiti in čakati na popoln načrt, ki nikoli ne pride. Po drugi strani pa nas spominjata, da lahko hitenje s spremembami brez premisleka povzroči še hujše težave.

V kodi to pomeni iskanje ravnovesja med tem, da se lotimo dela, in tem, da ne improviziramo strukturnih sprememb brez premisleka . Nedoločeno odlašanje določenih ključnih nalog je običajno slaba ideja, vendar tudi nenehno prekinjanje dela zaradi iskanja vsake nove ideje ne pomaga.

Idealen pristop je običajno obravnavati razvoj sistema kot iterativni proces: uvesti merljive spremembe in oceniti njihov vpliv , izboljšati ... in vzdrževati jasen seznam opravil, da pomembnih vprašanj ne pustimo »za vedno«.

16. Če je izvedbo težko razložiti, je to slaba ideja.

Če potrebujete zapleten odstavek, da razložite, kako deluje del kode, težava verjetno ni v vaših komunikacijskih veščinah, temveč v sami zasnovi. Ta aforizem nas spodbuja, da razlago uporabimo kot preizkus trdnosti zasnove.

Ko je implementacija tako kompleksna, da jo je težko preprosto razložiti, to običajno pomeni, da je preveč prekrivajočih se odgovornosti , slabo opredeljenih odvisnosti ali odločitev, ki niso bile temeljito preverjene. To je znak, da je pred sprejetjem tega pristopa priporočljivo refaktoriranje.

To merilo je zelo uporabno tako v Pythonu kot v C-ju: če v nekaj stavkih ne morete razložiti, kaj funkcija ali modul počne , je običajno prostor za strukturne izboljšave.

17. Če je implementacijo enostavno razložiti, je to morda dobra ideja.

Druga plat prejšnje točke je, da ko lahko rešitev opišete jasno, jedrnato in preprosto, ste verjetno na pravi poti. To ne zagotavlja, da je ideja popolna, je pa dober znak, da je kompleksnost pod nadzorom.

To načelo se zelo dobro ujema s praksami, kot je "tehnika gumijaste račke": če na glas razložite, kaj vaša koda počne drugi osebi (ali neživemu predmetu), pomagate odkriti nedoslednosti in potrditi, kdaj je nekaj dobro premišljeno.

V kontekstu ekipe je veliko lažje pregledovati, vzdrževati in razvijati ta del sistema, če lahko kateri koli član ekipe po kratki razlagi hitro razume, kaj del kode počne.

18. Imenski prostori so odlična ideja: naredimo jih več

Zadnji aforizem poudarja pomen imenskih prostorov kot orodja za organizacijo kode in izogibanje konfliktom. V Pythonu moduli, paketi, razredi in funkcije zagotavljajo različne ravni enkapsulacije in ločevanja odgovornosti.

Dosledna uporaba imenskih prostorov omogoča, da identifikatorji z istim imenom obstajajo v različnih kontekstih brez konfliktov, in pomaga združiti povezane elemente pod eno logično streho. Širitev uporabe teh mehanizmov pogosto vodi do bolj modularnih arhitektur.

V jeziku C, kjer je sistem imenskih prostorov veliko bolj rudimentaren, se ta ideja prevede v konvencije poimenovanja, strukturiranje po datotekah glave in izvorne kode ter disciplinirano uporabo static in predpone, da se izognemo kolizijam. Razumen »zenovski C« bi povabil obravnavajte vsak modul kot majhen, dobro definiran imenski prostor.

Prevodi v španščino in kulturne nianse

Skozi leta je bilo predlaganih več prevodov teh aforizmov v španščino. Nekateri se odločijo za »Lepo je boljše kot grdo«, drugi za »Lepo je boljše kot grdo« in tako naprej. Vsi si prizadevajo ohraniti duh izvirnika, čeprav se neizogibno pojavijo slogovne nianse in besedne izbire, značilne za prevajalca.

V španščini iz Španije je običajno govoriti o tem, da je koda "lepa", "berljiva" ali "jasna" in se izogibati "hekerskim vdorom" ali "hitrim rešitvam ". Ista ideja je osnova izvirnega Zena, ki združuje resen ton s kančkom humorja, zlasti v aforizmu, ki omenja, da očiten način morda sprva ni tak, "razen če si Nizozemec".

Ti prevodi služijo tudi temu, da je besedilo dostopnejše ljudem, ki ne govorijo tekoče angleško, ne da bi pri tem pozabili na dejstvo, da so načela uporabna za kateri koli jezik in katero koli razvojno skupnost , ki presega ekosistem Pythona.

Je Zen Pythona šala ali sveto pravilo?

Znotraj same skupnosti Python poteka nekaj razprav o natančnem statusu jezika Zen. Po eni strani ga številni formalni dokumenti (PEP) navajajo kot motivacijo ali utemeljitev za odločitve , na poštnih seznamih ključnih razvijalcev pa se uporablja kot argument za ali proti določenim predlogom.

Po drugi strani pa nekateri zagovorniki poudarjajo, da uporaba zenovske fraze kot orožja (»to krši zen, zato je slabo«) ni vedno smiselna. Obstajajo celo politično neodvisno govorniki, ki komentirajo, da so bili nekateri aforizmi nekoč interpretirani kot kritika samega jezika v njegovih zgodnjih fazah in jih ne bi smeli jemati dobesedno.

Resničnost je, da Zen deluje bolje kot kulturni kompas in vir navdiha kot pa kot strogo pravilo oblikovanja. Python je sčasoma vključil funkcije (kot so dodeljevanje v izrazih ali ujemanje vzorcev), ki jih nekateri smatrajo za bolj "kompleksne" ali manj usklajene z izvirno preprostostjo, pa so bile kljub temu sprejete zaradi svoje uporabnosti.

V tem smislu bi razmišljanje o »zenovskem C-ju« bolj pomenilo zajemanje splošnih načel , ki pomagajo pisati boljšo kodo v jeziku C, ne da bi pri tem nameravali, da ta načela postanejo nefleksibilni zakoni, ki blokirajo kakršen koli razvoj sloga ali orodij.

Ta zbirka aforizmov, prevodov, primerov in razprav tvori nekakšen miselni zemljevid, kako razumemo »dobro kodo«: berljivo, čim preprostejšo, eksplicitno v svojih namenih in premišljeno strukturirano. Ne glede na to, ali gre za Python, C ali kateri koli drug jezik, sprejetje te filozofije pogosto naredi razliko med programom, ki ga je težko napisati, in programom, s katerim je užitek delati.