Ano ang Zen ng Python at paano ito nagbibigay-inspirasyon sa isang posibleng Zen C

Kapag pinag-uusapan natin ang pilosopiya ng disenyo sa mga wika ng programmingKaraniwang lumalabas ang mga sumusunod Ang kilalang Zen ng Python: ang koleksyon ng mga aphorismo na lumilitaw kapag nagsusulat import this sa console. Gayunpaman, madaling malito ang ideyang ito sa isang diumano'y "Zen C programming language" o sa paghahanap ng katumbas na "Zen" sa loob mismo ng wikang C. Sa pagsasagawa, ang mayroon tayo ay isang serye ng mga prinsipyo na nagbigay inspirasyon sa mga komunidad tulad ng Python at sinusubukan ng maraming developer na gamitin ang ibang mga wika tulad ng C, sa halip na isang bagong wika na tinatawag na Zen C.

Sa artikulong ito, gagamitin natin ang pundasyong iyan upang ipaliwanag nang detalyado kung ano ang Zen ng Python, kung paano ito gumagana, Anong pilosopiya ang ipinapahayag nito, at hanggang saan nito mabibigyang-inspirasyon ang isang hipotetikal na Zen ng C?Susuriin natin ang mga aphorismo isa-isa, tatalakayin ang mga praktikal na halimbawa, mga nuances, at mga totoong kontradiksyon sa pag-unlad ng wika, at magtatapos sa pamamagitan ng isang pagninilay kung paano mailalapat ang mga prinsipyong ito sa labas ng ekosistema ng Python.

Ano nga ba talaga ang Zen (at bakit mahalaga ito kapag pinag-uusapan natin ang Zen C)

Ang tinatawag na Zen ng Python, na kilala rin bilang PEP 20Ito ay isang koleksyon ng mga aphorismo na sumasalamin sa pananaw ni Tim Peters kung paano dapat ang disenyo at pagsulat ng Python code. Bagama't maraming tao ang nagbabanggit nito na parang isang uri ng konstitusyon, ito ay nagmula bilang isang medyo magaan na teksto, na may kaunting ironya at kaunting katatawanan.

Ang mga aphorismong ito ay itinuturing na isang uri ng manipesto ng mabubuting gawiHindi ito mga pormal na tuntunin ng wika, ngunit malaki ang naimpluwensyahan ng mga ito sa kultura ng komunidad, sa pagsulat ng mga PEP (Python Enhancement Proposals), at mga debate tungkol sa ebolusyon ng wika mismo: mula sa pagpapakilala ng operator na "walrus" (:=) hanggang sa pagtutugma ng mga padron ng istruktura.

Kapag pinag-uusapan ng mga tao ang tungkol sa "Zen C," marami ang talagang nagtataka kung mayroong katumbas na hanay ng mga prinsipyo para sa C, o kung maaari ba itong iakma. pilosopiya ng pagiging simple, kalinawan, at pagiging madaling basahin sa konteksto ng wikang C, na mas mababa ang antas at hindi gaanong "palakaibigan" sa disenyo nito kaysa sa Python.

Sa pagsasagawa, kapag binabanggit ng isang tao ang Zen C, kadalasan ay sinusubukan nilang makuha ang parehong ideya: isang maliit na gabay upang makatulong sa pagsulat ng mas malinaw at mas napapanatiling C code, na inspirasyon ng ipinangangaral ng Zen ng Python, bagaman Walang opisyal na PEP 20 para sa C o isang magic module na katulad nito. import this.

Ano ang hitsura ng Zen ng Python sa console

Isa sa mga pinakakilalang kakaibang katangian ng Python ay ang pagpapakita ng Zen sa kahit anong interactive interpreter sa pamamagitan lamang ng pag-type import thisSimula noong Python 2.2.1, isinama na ng interpreter ang modyul this.py na, kapag inangkat, ay naglilimbag ng mga aphorismo sa Ingles.

Ang tekstong lumalabas ay isang serye ng 19 na maiikling pangungusap na nagbubuod sa pilosopiya ng disenyo ng Python. Sinasabing si Peters ay nagsalita tungkol sa 20 prinsipyo, ngunit Labing-siyam na sulatin lamang ang iniwan niya, iniiwan ang ikadalawampu bilang isang aporismong "multo" na maaaring bigyang-kahulugan o punan sa isip ng bawat tao.

Sa loob, ang modyul this Hindi nito iniimbak ang Zen sa simpleng teksto, kundi sa isang naka-encode na string na may ROT13 Simple lang. Ang modyul mismo ay tumutukoy sa isang diksyunaryo ng pagpapalit ng karakter at nagde-decode ng string bago ito i-print. Kung susuriin mo this.sMakikita mo ang obfuscated na bersyon; kung ilalapat mo ang substitution algorithm, makukuha mo ang nababasang teksto.

Ang paggamit na ito ng ROT13 ay may makasaysayang katangian: bago pa man umiral ang modyul, ang Zen ay ibinahagi na sa mailing list ng Python, na pinalalabo rin, bilang isang uri ng Itlog ng Pasko ng Pagkabuhay para sa komunidadAng ideya ng "i-import ito" ay naging slogan pa nga para sa mga naunang kumperensya sa ecosystem, tulad ng ika-10 International Python Conference.

Ang 19 na aphorismo ng Zen at ang kanilang praktikal na kahalagahan

Ang orihinal na teksto, sa Ingles, ay nagsisimula sa pamagat na “The Zen of Python, by Tim Peters” at pagkatapos ay nagpapakita ng 19 na pangungusap na nabasa na ng bawat gumagamit ng Python sa isang punto. Mula rito, susuriin natin ang mga ito isa-isa, na nagpapaliwanag ang ipinahihiwatig ng mga ito sa pang-araw-araw na coding, kung paano karaniwang binibigyang-kahulugan ang mga ito at ilang tipikal na halimbawa sa Python na makakatulong sa atin na isipin kung paano ito maisasalin sa isang "Zen C".

1. Mas mabuti ang maganda kaysa sa pangit

Binibigyang-diin ng unang tuntunin na ang kodigo ay hindi lamang dapat gumana, kundi dapat ding masarap basahinAng kagandahan dito ay hindi tungkol sa mga palamuti, kundi tungkol sa kalinawan, pagkakapare-pareho, at maingat na istilo: mga pangalang madaling maunawaan, mga espasyong maayos ang pagkakalagay, at malinis na istruktura.

Ang isang klasikong halimbawa sa Python ay ang pagpili ng mga operator at keyword na nababasa ng tao tulad ng and y or laban sa mga simbolo maging misteryoso kapag mayroon, o iwasan ang pagkakaroon ng maraming iba't ibang operasyon na nakasalansan sa iisang linya sa pamamagitan ng pagsasakripisyo ng pagiging madaling mabasa para sa kaiklian.

Ang parehong ideya na inilapat sa isang hipotetikal na Zen C ay magmumungkahi ng paggamit malinaw na mga kombensiyon sa pag-ukit, mga naglalarawang pangalan at paghiwalayin ang mga kumplikadong ekspresyon sa ilang linya, sa halip na abusuhin ang mga macro o masalimuot na ekspresyon na tanging ang taong sumulat lamang ng mga ito ang nakakaintindi.

2. Mas mainam ang tahasan kaysa sa implicit

Binibigyang-diin ng prinsipyong ito na hindi dapat hulaan ng mambabasa ng code kung paano gumagana ang isang bagay. Mas mainam kung malinaw ang layunin. isinulat sa liwanag ng araw, bagama't maaaring may kasama itong ilan pang linya, sa halip na umasa sa di-tuwirang pag-uugali o nakatagong "mahika".

Isang karaniwang halimbawa ay ang pag-iwas sa mga bagay tulad ng from math import *na nagdadala ng lahat ng nilalaman ng isang module sa kasalukuyang namespace nang hindi nililinaw kung ano ang ginagamit. Mas mainam na isulat from math import sqrt, sin, cos at malinaw na sabihin kung ano ang kinakailangan.

Ang isa pang paraan upang maging malinaw ang code ay ang pagpapakilala mga intermediate variable na may mga nagpapahayag na pangalan Sa halip na pagsama-samahin ang mga operasyon sa iisang ekspresyon. Nakakatulong iyan sa sinuman (kasama na ang iyong magiging sarili) na maunawaan kung ano ang nangyayari nang hindi kinakailangang gumawa ng mental reverse engineering.

3. Mas mainam ang simple kaysa sa kumplikado

Ang ideya rito ay, kapag mayroon kang pagpipilian, piliin ang simpleng solusyon kaysa sa masalimuot na solusyonHindi ito tungkol sa pag-iwas sa lahat ng komplikasyon anuman ang mangyari, kundi tungkol sa pag-alala na ang code ay isinusulat nang isang beses at binabasa nang maraming beses.

Madalas iginigiit ng mga bihasang programmer na ang pagkamit ng pagiging simple ay nangangailangan ng pagsisikap: kailangan mong pinuhin ang disenyo, kunin ang mga function, suriin ang mga pangalan… ngunit bilang kapalit ay makukuha mo Malinis at mahusay na code Madali itong maunawaan at maaaring mapanatili nang walang pangamba. Ang pamamaraang ito ay gumagana para sa parehong Python at C: mas mainam ang isang maikli at malinaw na function kaysa sa isang mega-function na puno ng mga espesyal na kaso at status flag.

Ang mga halimbawa ay kadalasang naghahambing sa mga implementasyon kung saan ang lahat ay nireresolba sa isang cryptic line na may medyo mas mahabang mga bersyon, ngunit may malinaw at mahusay na natukoy na mga bloke ng lohikana mas madaling ipaliwanag.

4. Mas mainam ang kumplikado kaysa sa kumplikado

Mahalaga ang pagkakaiba sa pagitan ng "kumplikado" at "kumplikado". Ang isang komplikadong sistema ay binubuo ng mga simpleng modyul na pinagsasama-samaNgunit ang bawat piraso, kung titingnan nang hiwalay, ay mauunawaan. Sa kabilang banda, ang isang kumplikadong sistema ay puno ng mga nakatagong dependency, mga ibinahaging estado, at lohika na hindi agad nakikita.

Sa code, isinasalin ito sa pagpili ng mga disenyo kung saan ang bawat function ay lumulutas ng isang malinaw na gawain at umaasa sa iba pang mahusay na natukoy na mga function, sa halip na itambak ang lahat ng lohika sa isang lugar na gumagamit ng mga global constant, implicit states, at mahirap sundin na mga cross-condition.

Ang inordered preference ay karaniwang ibubuod bilang Simple > Komplikado > KomplikadoSa madaling salita, kung hindi posible na maging ganap na simple, kahit man lang hayaang maging istrukturado ang kasalimuotan at hindi isang hindi mabasang kaguluhan.

5. Mas mainam ang patag kaysa sa naka-nest

Ang malalim na pagpugad ay ang kaaway ng mabilis na pag-unawa. Maraming antas ng ifAng mga loop sa loob ng mga loop at nested structure ay pumipilit sa mambabasa na labis na pag-overload ng iyong ulo ng napakaraming impormasyon kasabay nito. Ang rekomendasyon ng Zen ay patagin tuwing makatuwiran.

Ang isang tipikal na pamamaraan para maiwasan ang walang katapusang mga pugad ay kunin ang mga bahagi ng code sa maliliit na helper functiono gumamit ng mas direktang istruktura ng kontrol (tulad ng elif sa halip ng else: if ... Maaari ka ring gumamit ng mga generator o purong mga function na nagbibigay-daan sa iyong iproseso ang mga koleksyon nang walang mga loop sa loob ng mga loop.

Sa Python, maaaring kasama rito ang pagbabago ng tatlong nested for loops tungo sa isang serye ng chained generator functions; sa C, hatiin ang napakalalim na mga tungkulin sa ilang mas patag na mga tungkulin Binabawasan nito ang biswal at lohikal na pagiging kumplikado ng bawat piraso.

6. Mas mainam ang nakakalat kaysa sa siksik

Ang sobrang siksik na code ay maaaring mukhang elegante sa unang tingin, ngunit kadalasan ito ay isang sakit para sa taong dapat sumuporta sa kanyaHinihikayat ng Zen ang pagbibigay ng espasyo para makahinga: paghihiwalay ng mga lohikal na bloke sa iba't ibang linya, pagpapasok ng mga espasyo at pahinga sa linya kung kinakailangan.

Isang napaka-ilustratibong kaso ay Isama ang mga kondisyonal, mga pahayag ng pagbabalik, at mga tawag sa function sa iisang linyaPosible, ngunit mahal ang kapalit ng pag-unawa. Ang paghahati ng lohikang iyan sa ilang linya na may mga pangalang panlahat ay ginagawang napakalinaw ng daloy.

Sa Python, inirerekomenda ang mga nababasang pag-unawa sa listahan at maiikling ekspresyon; sa C, ganito rin ang naaangkop sa paggamit ng mga operator, macro, at chained call, na ipinapayong gamitin. i-deploy sa mga pansamantalang hakbang kapag nagsimula na silang maging misteryoso.

7. Mahalaga ang pagiging madaling mabasa

Ang pariralang "Napakahalaga ng pagiging madaling mabasa" ay halos naging isang slogan na Python. Ang mensahe ay diretso: Ang code ay binabasa nang walang katapusang mas maraming beses kaysa sa naisusulatKaya, kailangan itong i-optimize para sa taong magbabasa nito, hindi para sa taong unang beses na magta-type nito.

Ang syntax mismo ng Python ay dinisenyo nang may ganitong prayoridad: Sapilitang pag-indent, malinaw na mga keyword, at ilang alternatibong paraan upang gawin ang parehong bagaySa ibang mga wika, tulad ng C, ang pagiging madaling mabasa ay higit na nakasalalay sa istilo ng pangkat: paggamit ng mga kombensiyon sa pagpapangalan, makabuluhang mga komento, mahusay na natukoy na mga modyul, atbp.

Sa parehong mga kaso, ang mga pamamaraan tulad ng paglalapat ng mga prinsipyo ng SOLID, pagkuha ng inspirasyon mula sa mga ideya ng "Clean Code", o palaging paggamit ng mga pangalan na nagpapaliwanag ng intensyon ay nakakatulong sa programa na maging mas napapanatili sa pangmatagalan at maaaring sumali ang mga bagong developer nang walang paghihirap.

8. Ang mga espesyal na kaso ay hindi gaanong espesyal para lumabag sa mga patakaran

Tinutugunan ng talinghagang ito ang paulit-ulit na tukso na sabihing, “Iba ang kasong ito; gagawa tayo ng eksepsiyon dito.” Kapag tumutukoy sa isang hanay ng mga tuntunin sa estilo o disenyo, kung Ang bawat kakatwang bagay ay ginagamit na dahilan para laktawan ang mga itoSa huli, walang silbi ang mga patakaran.

Iminumungkahi ni Zen na, kahit sa mga "espesyal" na kaso, mas mainam na sikaping mapanatili ang pagkakapare-parehoNangangahulugan ito ng pag-aangkop sa disenyo upang umangkop sa partikular na sitwasyon, sa halip na palihim na gumamit ng shortcut na makakasira sa pangkalahatang kalinawan ng sistema.

Ang prinsipyong ito ay lalong mahalaga kapag nagdidisenyo ng mga API, format ng datos, o mga alituntunin sa istilo sa isang malaking pangkat, kung saan ang bawat eksepsiyon ay kumakatawan sa isang hamon. karagdagang cognitive load para sa lahat.

9. Bagama't nananalo ang praktikalidad kaysa sa kadalisayan

Ang dalawang aphorismong ito (mga tuntunin at praktikalidad) ay nagbabalanse sa isa't isa. Sa isang banda, hinihingi ang pagiging pare-pareho; sa kabilang banda, kinikilala na sa totoong buhay Hindi tayo maaaring laging maging ganap na "dalisay" Sa disenyo, kung minsan ay kinakailangan ang mga praktikal na shortcut upang matugunan ang mga deadline, umangkop sa mga limitasyon sa kapaligiran, o mapadali ang pag-aampon ng isang solusyon.

Ang susi ay huwag magpadala sa sobrang pagkahumaling: maaaring bigyang-katwiran ng pagiging praktikal mga praktikal na shortcut upang matugunan ang mga deadlineNgunit hindi iyon dapat maging dahilan para tanggapin ang anumang mababang uri ng trabaho. Ang isang tipikal na halimbawa sa Python ay ang paggamit ng mga maigsi na construct kapag talagang pinapabuti nito ang code, nang hindi gumagamit ng "itim na mahika" na kailangang maintindihan.

Sa isang hipotetikal na Zen C, makikita ito sa mga desisyon tulad ng tanggapin ang ilang partikular na paggamit ng mga macro o mga partikular na pag-optimize compiler kapag talagang pinapabuti nila ang performance nang hindi ginagawang hindi maintindihan ang code.

10. Hindi dapat balewalain ang mga pagkakamali.

Tinutugunan ng gabay na ito ang paghawak ng mga eksepsiyon at error. Mga konstruksyon ng bloke try/except ganap na generic na ginagawa lang pass Ang mga ito ay isang siguradong sangkap para sa mga problemang mahirap i-debug: may nagkamali, walang nakakapansin, at tila lumilitaw ang mga hindi inaasahang pangyayari pagkalipas ng ilang buwan.

Inirerekomenda ni Zen na, maliban sa mga kaso ng sadyang pagpapasya, dapat ipakita ang mga pagkakamali: na tanging ang mga nilalayong uri lamang ang dapat makuha, na itala ang mga ito sa mga talaNa magpadala ng malinaw na mga mensahe o kahit na ihinto ang pagpapatupad kung hindi alam ng sistema kung paano makabawi.

Sa C, sistematikong hindi pinapansin ang mga return code o hindi pagsuri para sa mga null pointer Ito ay isang garantisadong paraan upang gawing isang bangungot ang pagpapanatili.

11. Maliban na lang kung tahasang pinatahimik ang mga ito

Tulad ng ibang mga patakaran, mahalaga ang mga detalye rito. May mga sitwasyon kung saan alam mo ang isang partikular na pagkakamali, pinag-aralan mo ang mga implikasyon nito, at napagpasyahan mo na Hindi ito kritikal, o na mayroon kang kontroladong paraan ng pagkilosSa mga kasong iyon, maaaring makatuwiran ang tahasang pagpapatahimik sa kanya.

Ang isang tipikal na halimbawa ay makunan ang isang ValueError partikular at sumulat ng mensahe ng debug na nagpapahiwatig na ito ay nahawakan nang tamanang hindi na pinapalawig pa ang eksepsiyon. Gayunpaman, ang susi ay maging isang sinasadya at dokumentadong desisyon ito, hindi isang paraan upang pagtakpan ang mga problema.

Sa C, ang katumbas ay magiging pamahalaan ang isang kilalang error code sa pamamagitan ng pagbabalik ng isang dokumentadong default na halaga, itinatala ang kaganapan kung naaangkop, at sa kontekstong iyon lamang at binabalewala ang pagkabigo nang hindi nagka-crash ang application.

12. Kapag nahaharap sa kalabuan, tanggihan ang tuksong manghula.

Itinatampok ng aphorismong ito ang isang karaniwang patibong: ang pagpupuno sa mga puwang sa isipan kapag hindi malinaw ang mga kinakailangan, disenyo, o maging ang mismong kodigo. Itinataguyod ng Zen ang Huwag kang mag-imbento ng mga kahulugan kung saan wala naman talaga.Kung ang isang bagay ay hindi malinaw, pinakamahusay na pilitin ang isang tahasang desisyon.

Sa code, isinasalin ito sa mga pangalan ng function na nagpapaliwanag nang eksakto kung ano ang kanilang ginagawa, mga komento na naglilinaw sa mahahalagang pagpapalagay, at, higit sa lahat, mga pagsubok na tumutukoy sa inaasahang pag-uugaliKung hindi alam kung ano ang dapat mangyari, ang code ay magiging "panghuhula" lamang at halos tiyak na mali.

Kapag inilapat ang prinsipyong ito sa isang potensyal na Zen C, ito ay nagiging isang palaging paalala: Huwag ipagpalagay na gagawin ng compiler, platform, o standard library ang inaasahan mo. nang hindi pa ito napatutunayan sa dokumentasyon o sa mga konkretong pagsusuri.

13. Dapat ay isa lamang ang malinaw na paraan upang gawin ito

Ang prinsipyong ito ay halos nasa puso ng pagkakakilanlan ng Python. Kabaligtaran ng mga motto tulad ng kay Perl ("Mayroong higit sa isang paraan para gawin ito"), sinisikap ng Python na tiyakin na, para sa isang partikular na gawain, mayroong malinaw na mas gustong landasPinapasimple nito ang pag-aaral at ginagawang mas pare-pareho ang code mula sa iba't ibang tao.

Isang klasikong halimbawa ay ang pag-ulit sa mga sequence. Sa Python, isang napaka-espesipikong pamamaraan ang itinataguyod: for elemento in secuencia:Sa halip na pilitin ang manu-manong pag-index maliban kung kinakailangan, ginagawang halos walang saysay ang mga reading loop.

Para sa C, ang diwang ito ay maaaring isalin sa pag-aampon, sa antas ng pangkat, Mga karaniwang pattern para sa mga paulit-ulit na operasyon: isang karaniwang paraan ng pagdaan sa mga array, pamamahala ng memorya, o paghawak ng mga error, sa halip na ang bawat developer ay mag-imbento ng sarili nilang istilo.

14. Bagama't maaaring hindi mukhang halata ang paraang iyon sa simula (maliban na lang kung ikaw ay Dutch)

Ang talinghagang ito ay nagdaragdag ng kaunting pahiwatig: ang mas gustong paraan ay hindi laging halata sa simula. Kadalasan, kailangan munang maging pamilyar sa wika, sa mga aklatan nito, at sa ecosystem nito para maging natural ang "halatang paraan" na iyon.

Ang pagbanggit sa Dutch ay direktang pagtukoy kay Guido van Rossum, ang lumikha ng Python, na isang Dutch. Para sa kanya, maraming desisyon sa disenyo ang maaaring maging madaling maunawaan dahil alam niya nang eksakto kung ano ang kanyang nilalayon; para sa iba, nangangailangan ito ng mas maraming karanasan. isang panahon ng pag-aangkop at pagkatuto.

Ganito rin ang mangyayari sa kahit anong impormal na "Zen C": ang tila halata sa mga beterano sa wika (kung paano gumamit ng mga pointer, kung paano isaayos ang mga header, kung paano buuin ang isang proyekto) ay maaaring maging lubhang hindi malinaw sa isang taong bago sa paksa.

15. Mas mabuti na ngayon kaysa dati, bagama't kadalasan ay wala nang mas mabuti kaysa ngayon.

Ang dalawang aphorismong ito ay nagsasalita tungkol sa mga prayoridad at tiyempo. Sa isang banda, hinihikayat tayo ng mga ito na huwag mahulog sa paralisis ng pagsusuri: Mas mainam na gumawa ng makatuwirang pag-unlad kaysa sa walang gawin. Naghihintay ng perpektong disenyo na hindi dumarating. Sa kabilang banda, nagsisilbi itong paalala na ang pagmamadali sa pagbabago ng mga bagay-bagay nang hindi nag-iisip ay maaaring lumikha ng mas malala pang problema.

Sa code, isinasalin iyon sa Paghahanap ng balanse sa pagitan ng pagsisimula sa trabaho at hindi pag-iimprovise ng mga pagbabago sa istruktura nang hindi nag-iisipAng pagpapaliban ng ilang mahahalagang gawain nang walang katiyakan ay kadalasang masamang ideya, ngunit ang patuloy na pag-abala sa iyong ginagawa para habulin ang bawat bagong ideya ay hindi rin nakakatulong.

Ang mainam na pamamaraan ay karaniwang ituring ang ebolusyon ng sistema bilang isang prosesong paulit-ulit: magpakilala ng mga nasukat na pagbabago at suriin ang kanilang epektoPinuhin… at panatilihin ang isang malinaw na listahan ng mga dapat gawin upang hindi maiwan ang mahahalagang isyu "nang tuluyan".

16. Kung mahirap ipaliwanag ang implementasyon, masamang ideya iyon.

Kung kailangan mo ng isang masalimuot na talata upang ipaliwanag kung paano gumagana ang isang piraso ng code, ang problema ay malamang na hindi ang iyong mga kasanayan sa komunikasyon, kundi ang disenyo mismo. Hinihikayat ng aphorismong ito ang paggamit ng paliwanag bilang pagsusuri sa kalusugan ng disenyo.

Kapag ang isang implementasyon ay napakakumplikado na mahirap ipaliwanag sa mga simpleng salita, kadalasan itong nangangahulugan na mayroong napakaraming magkahalong responsibilidadAng mga hindi maayos na tinukoy na mga dependency o mga hindi nilinis na desisyon ay isang senyales na ipinapayong mag-refactor bago tanggapin ang pamamaraang iyon.

Ang pamantayang ito ay lubhang kapaki-pakinabang sa parehong Python at C: Kung hindi mo maipaliwanag sa ilang pangungusap kung ano ang ginagawa ng isang function o moduleKaraniwan, may puwang para sa pagpapabuti ng istruktura.

17. Kung madaling ipaliwanag ang implementasyon, maaaring magandang ideya ito

Ang kabilang panig ng naunang punto ay kapag nailarawan mo ang isang solusyon sa malinaw, maigsi, at prangka na mga termino, malamang na nasa tamang landas ka. Hindi nito ginagarantiyahan na perpekto ang ideya, ngunit isa itong magandang senyales na nasa tamang landas ka. kontrolado na ang pagiging kumplikado.

Ang prinsipyong ito ay lubos na nauugnay sa mga kasanayan tulad ng "rubber duck technique": ang pagpapaliwanag nang malakas kung ano ang ginagawa ng iyong code sa ibang tao (o isang walang buhay na bagay) ay nakakatulong upang matukoy ang mga hindi pagkakapare-pareho at kumpirmahin kung ang isang bagay ay pinag-isipang mabuti.

Sa konteksto ng isang pangkat, kung mabilis na mauunawaan ng sinumang miyembro ng pangkat kung ano ang ginagawa ng isang piraso ng code pagkatapos ng isang maikling paliwanag, mas madaling suriin, panatilihin, at paunlarin ang bahaging iyon ng sistema.

18. Magandang ideya ang mga namespace: gawin pa natin ang higit pa sa mga ito

Itinatampok ng huling aphorismo ang kahalagahan ng mga namespace bilang isang kasangkapan para sa pag-oorganisa ng code at pag-iwas sa mga banggaan. Sa Python, ang mga module, package, class, at function ay nagbibigay ng iba't ibang antas ng organisasyon. enkapsulasyon at paghihiwalay ng mga responsibilidad.

Ang patuloy na paggamit ng mga namespace ay nagbibigay-daan sa mga identifier na may parehong pangalan na umiral sa iba't ibang konteksto nang walang mga salungatan, at nakakatulong sa pagpapangkat ng mga magkakaugnay na elemento sa ilalim ng iisang lohikal na payong. Ang pagpapalawak ng paggamit ng mga mekanismong ito ay kadalasang humahantong sa mas modular na mga arkitektura.

Sa C, kung saan ang sistemang namespace ay mas simple, ang ideyang ito ay isinasalin sa mga kombensiyon sa pagpapangalan, pagbubuo ayon sa header at source file, at disiplinadong paggamit ng static at mga unlapi upang maiwasan ang mga banggaan. Ang isang makatwirang "Zen C" ay mag-aanyaya ituring ang bawat module bilang isang maliit at mahusay na namespace.

Mga pagsasalin sa Espanyol at mga kultural na nuances

Sa paglipas ng mga taon, ilang salin ng mga aphorismong ito sa Espanyol ang iminungkahi. Ang ilan ay pumipili ng "Mas mabuti ang maganda kaysa sa pangit," ang iba naman ay para sa "Mas mabuti ang maganda kaysa sa pangit," atbp. Lahat ay naghahangad na mapanatili ang diwa ng orihinal, bagama't may ilang mga baryasyon na hindi maiiwasang lumitaw. mga nuances ng estilo at pagpili ng bokabularyo katangian ng tagasalin.

Sa Espanyol mula sa Espanya, karaniwang tinutukoy ang kodigo bilang "maganda", "mababasa" o "malinaw", at ng iwasan ang mga "bote" o "mabilisang pag-aayos"Ang ideya ring iyan ang saligan ng orihinal na Zen, na pinaghalo ang seryosong tono na may kaunting katatawanan, lalo na sa aphorismo na bumabanggit na ang malinaw na paraan ay maaaring hindi ganito sa simula "maliban na lang kung ikaw ay Olandes".

Ang mga saling ito ay nagsisilbi rin upang gawing mas madaling maunawaan ang teksto ng mga taong hindi matatas sa Ingles, nang hindi nakakaligtaan ang katotohanan na ang mga prinsipyo ay naaangkop. sa anumang wika at anumang komunidad ng pag-unladlampas sa ekosistema ng Python.

Biro ba o sagradong tuntunin ang Zen ng Python?

Sa loob mismo ng komunidad ng Python, mayroong ilang debate tungkol sa eksaktong katayuan ng Zen. Sa isang banda, maraming pormal na dokumento (PEP) ang binabanggit ito bilang motibasyon o katwiran ng mga desisyon, at sa mga mailing list ng mga pangunahing developer, ginagamit ito bilang argumento pabor o laban sa mga partikular na panukala.

Sa kabilang banda, itinuro ng ilang tagapagbigay ng maintenance na gamitin ang pariralang Zen bilang sandata ("Linalabag nito ang Zen, samakatuwid ito ay masama") ay hindi laging may katuturan. Mayroon ding mga PEP na nagkokomento na ang ilang mga aphorismo ay dating binibigyang-kahulugan bilang mga kritisismo sa wika mismo sa mga simula nito at hindi dapat literal na unawain.

Ang katotohanan ay ang Zen ay pinakamahusay na gumagana bilang kultural na kompas at pinagmumulan ng inspirasyon na bilang isang mahigpit na tuntunin sa disenyo. Python, na may orasNagsama ito ng mga tampok (tulad ng pagtatalaga sa mga ekspresyon o pagtutugma ng padron) na itinuturing ng ilan na mas "kumplikado" o hindi gaanong nakahanay sa orihinal na pagiging simple, ngunit ginamit pa rin ang mga ito dahil sa kanilang kapakinabangan.

Sa ganitong diwa, ang pag-iisip tungkol sa isang "Zen C" ay may higit na kinalaman sa mga pangkalahatang prinsipyo ng pagkuha na nakakatulong sa pagsulat ng mas mahusay na C code, nang hindi nilalayong maging mga batas na hindi nababaluktot na humaharang sa anumang ebolusyon ng estilo o mga kagamitan.

Ang koleksyon na ito ng mga aphorismo, salin, halimbawa, at talakayan ay bumubuo ng isang uri ng mapa ng kaisipan kung paano natin nauunawaan ang "mabuting code": madaling basahin, kasingsimple hangga't maaari, malinaw sa mga layunin nito, at maingat na nakabalangkas. Nasa Python man, C, o anumang iba pang wika, Ang pag-aampon sa pilosopiyang iyan ay kadalasang gumagawa ng pagkakaiba sa pagitan ng isang programang mahirap at isa na kasiya-siyang gamitin..