Co je Zen Pythonu a jak inspiruje možný Zen C

Když mluvíme o filozofii designu v jazycích programováníJe obvyklé, že se objeví následující Známý Zen z Pythonu: ta sbírka aforismů, která se objevuje při psaní import this v konzoli. Je však snadné si tuto myšlenku zaměnit s myšlenkou údajného „programovacího jazyka Zen C“ nebo s hledáním ekvivalentního „Zenu“ v samotném jazyce C. V praxi máme spíše řadu principů, které inspirovaly komunity jako Python a které se mnoho vývojářů snaží extrapolovat do jiných jazyků, jako je C, než nový jazyk s názvem Zen C.

V tomto článku využijeme tento základ k podrobnému vysvětlení, co je Zen Pythonu, jak funguje, Jakou filozofii sděluje a do jaké míry může inspirovat hypotetický zen jazyka C?Aforismy si probereme jeden po druhém, probereme praktické příklady, nuance a skutečné rozpory ve vývoji jazyka a na závěr se zamyslíme nad tím, jak lze tyto principy aplikovat mimo ekosystém Pythonu.

Co je Zen doopravdy (a proč je důležitý, když mluvíme o Zen C)

Takzvaný Zen Pythonu, známý také jako PEP 20Je to sbírka aforismů, které shrnují vizi Tima Peterse o tom, jak by měl vypadat návrh a psaní kódu v Pythonu. Ačkoli ji mnoho lidí cituje, jako by to byla jakási ústava, ve skutečnosti vznikla jako relativně lehký text s notnou dávkou ironie a špetkou humoru.

Tyto aforismy jsou považovány za druh manifest osvědčených postupůNejedná se o formální pravidla jazyka, ale výrazně ovlivnila kulturu komunity, psaní návrhů PEP (Python Enhancement Proposals) a debaty o vývoji samotného jazyka: od zavedení operátoru „mrož“ (:=) až do shody strukturálních vzorů.

Když se mluví o „zenovém C“, mnoho lidí se ve skutečnosti ptá, zda existuje ekvivalentní sada principů pro C, nebo zda se to dá upravit. filozofie jednoduchosti, jasnosti a čitelnosti do kontextu jazyka C, který je na nižší úrovni a méně „přátelský“ ve svém designu než Python.

V praxi, když někdo zmíní Zen C, obvykle se snaží zachytit stejnou myšlenku: hrstku pokynů, které pomohou psát jasnější a lépe udržovatelný kód v jazyce C, inspirovaný tím, co káže Zen Pythonu, ačkoli Neexistuje žádný oficiální PEP 20 pro C ani magický modul jako... import this.

Jak vypadá Pythonovský Zen v konzoli

Jednou z nejznámějších kuriozit Pythonu je, že Zen lze zobrazit v libovolném interaktivním interpretu pouhým napsáním import thisOd verze Pythonu 2.2.1 má interpret integrovaný modul this.py který po importu vytiskne aforismy v angličtině.

Text, který se objeví, je série 19 krátkých vět, které shrnují filozofii designu Pythonu. Říká se, že Peters hovořil o 20 principech, ale Zanechal po sobě pouze 19 spisů, čímž dvacátý verš zůstává „přízračným“ aforismem, který si každý může interpretovat nebo si jej v duchu doplnit.

Interně modul this Neukládá Zen v prostém textu, ale v zakódovaném řetězci s ROT13 Jednoduché. Modul sám definuje slovník pro nahrazování znaků a dekóduje řetězec před jeho vytištěním. Pokud prohlédnete this.sUvidíte zmatenou verzi; pokud použijete substituční algoritmus, získáte čitelný text.

Toto použití ROT13 má historický náskok: předtím, než modul existoval, byl Zen sdílen na mailing listu Pythonu, také obfuskovaný, jako druh Velikonoční vajíčko pro komunituMyšlenka „importovat toto“ se dokonce stala sloganem pro první ekosystémové konference, jako například 10. mezinárodní konference o Pythonu.

19 zenových aforismů a jejich praktický význam

Původní text v angličtině začíná nadpisem „Zen Pythonu od Tima Peterse“ a poté představuje 19 vět, které každý uživatel Pythonu někdy četl. Dále si je budeme postupně procházet a vysvětlovat. co znamenají v každodenním kódování, jak se obvykle interpretují a několik typických příkladů v Pythonu, které nám pomáhají představit si, jak by se daly přeložit do „zenového C“.

1. Krásné je lepší než ošklivé

První pravidlo zdůrazňuje, že kód by měl nejen fungovat, ale měl by také být příjemné čteníKrása zde není o ozdobách, ale o jasnosti, konzistenci a pečlivém stylu: srozumitelné názvy, dobře umístěné prostory a čistá struktura.

Klasickým příkladem v Pythonu je preferování lidsky čitelných operátorů a klíčových slov, jako je and y or proti symboly kryptické, pokud jsou k dispozici, nebo se vyhnout hromadění několika různých operací na stejném řádku obětováním čitelnosti ve prospěch stručnosti.

Stejná myšlenka aplikovaná na hypotetický Zen C by naznačovala použití jasné konvence odsazení, popisné názvy a oddělovat složité výrazy do několika řádků, místo zneužívání maker nebo složitých výrazů, kterým rozumí pouze osoba, která je napsala.

2. Explicitní je lepší než implicitní

Tato zásada zdůrazňuje, že čtenář kódu by neměl muset hádat, jak něco funguje. Je lepší, aby byl záměr jasný. psané za bílého dne, i když to může zahrnovat o několik řádků více, spíše než spoléhat se na implicitní chování nebo skrytou „magii“.

Velmi častým příkladem je vyhýbání se věcem, jako je from math import *které přenášejí veškerý obsah modulu do aktuálního jmenného prostoru, aniž by bylo jasné, co se používá. Je lepší napsat from math import sqrt, sin, cos a explicitně uvést, co je potřeba.

Dalším způsobem, jak explicitně specifikovat kód, je zavést mezilehlé proměnné s expresivními názvy Místo hromadění operací do jednoho výrazu. To pomáhá komukoli (včetně vašeho budoucího já) pochopit, co se děje, aniž by musel provádět mentální reverzní inženýrství.

3. Jednoduché je lepší než složité

Myšlenka je, že když máte možnost, zvolte jednoduché řešení před složitýmNejde o to vyhnout se veškeré složitosti za každou cenu, ale o to si pamatovat, že kód se napíše jednou a přečte mnohokrát.

Zkušení programátoři často trvají na tom, že dosažení jednoduchosti vyžaduje úsilí: musíte vylepšit design, extrahovat funkce, zkontrolovat názvy… ale na oplátku dostanete Čistý a efektivní kód Je snadno pochopitelný a lze jej bez obav spravovat. Tento přístup funguje jak pro Python, tak pro C: krátká a jasná funkce je vhodnější než megafunkce plná speciálních případů a stavových příznaků.

Příklady často porovnávají implementace, kde je vše vyřešeno v jednom kryptickém řádku, s poněkud delšími verzemi, ale s... jasné a dobře definované logické blokykteré se mnohem snáze vysvětlují.

4. Složité je lepší než složité

Rozdíl mezi „složitým“ a „komplikovaným“ je důležitý. Složitý systém se skládá z jednoduché moduly, které se dají kombinovatAle každá část, posuzovaná samostatně, je pochopitelná. Složitý systém je na druhou stranu plný skrytých závislostí, sdílených stavů a ​​logiky, která není na první pohled zřejmá.

V kódu se to promítá do preference návrhů, kde každá funkce řeší jasný úkol a spoléhá se na další dobře definované funkce, namísto hromadění veškeré logiky na jednom místě, které používá globální konstanty, implicitní stavy a obtížně sledovatelné křížové podmínky.

Seřazená preference se obvykle shrnuje jako Jednoduché > Složité > KomplikovanéJinými slovy, pokud není možné být zcela jednoduchý, ať je alespoň složitost strukturovaná a ne nečitelný chaos.

5. Plochý je lepší než vnořený

Hluboké vnoření je nepřítelem rychlého porozumění. Několik úrovní ifSmyčky uvnitř smyček a vnořené struktury nutí čtenáře zahlcování hlavy příliš velkým množstvím informací zároveň. Zenové doporučení je provádět flatping, kdykoli je to rozumné.

Typickou technikou, jak se vyhnout nekonečným hnízdům, je extrahovat části kódu do malých pomocných funkcínebo použít přímější kontrolní struktury (jako například elif místo else: if ... vnořené). Můžete také použít generátory nebo čisté funkce, které umožňují zpracovávat kolekce bez smyček uvnitř smyček.

V Pythonu by to mohlo zahrnovat transformaci tří vnořených smyček for do série zřetězených generátorových funkcí; v jazyce C, segmentovat velmi hluboké funkce do několika plošších funkcí Snižuje vizuální a logickou složitost každého dílu.

6. Disperzní je lepší než husté

Extrémně kompaktní kód se může na první pohled zdát elegantní, ale často je... bolest pro toho, kdo ho musí podporovatZen doporučuje ponechat prostor pro dýchání: oddělovat logické bloky do různých řádků, vkládat mezery a zalamovat řádky, když je to nutné.

Velmi ilustrativním případem je Uveďte podmíněné výrazy, příkazy return a volání funkcí na jednom řádkuJe to možné, ale náklady na pochopení jsou vysoké. Rozdělení této logiky do několika řádků s mezilehlými názvy činí tok křišťálově jasným.

V Pythonu se doporučuje použití čitelných seznamů a krátkých výrazů; v jazyce C totéž platí pro použití operátorů, maker a zřetězených volání, které jsou vhodné. nasadit v mezikrocích když začnou být tajemné.

7. Čitelnost je důležitá

Fráze „Čitelnost se počítá“ se stala téměř sloganem Pythonu. Sdělení je jednoduché: Kód je přečten nekonečněkrát vícekrát, než je zapsánTakže je potřeba to optimalizovat pro toho, kdo to bude číst, ne pro toho, kdo to píše poprvé.

Samotná syntaxe Pythonu byla navržena s touto prioritou: Povinné odsazení, jasná klíčová slova a několik alternativních způsobů, jak udělat totéžV jiných jazycích, jako je například C, čitelnost mnohem více závisí na stylu týmu: používání konvencí pojmenování, smysluplných komentářů, dobře definovaných modulů atd.

V obou případech techniky, jako je aplikace principů SOLID, čerpání inspirace z myšlenek „Clean Code“ nebo vždy používání názvů, které vysvětlují záměr, pomáhají programu být dlouhodobě udržitelnější a noví vývojáři se mohou připojit bez problémů.

8. Zvláštní případy nejsou tak zvláštní, aby porušovaly pravidla

Tento aforismus se zabývá opakujícím se pokušením říci: „Tento případ je jiný; uděláme zde výjimku.“ Při definování souboru stylistických nebo designových pravidel, pokud Každá zvláštnost se používá jako výmluva k jejich vynecháníNakonec jsou pravidla k ničemu.

Zen naznačuje, že i ve „zvláštních“ případech je lepší usilovat o zachovat konzistenciTo znamená přizpůsobit design konkrétnímu případu, namísto vkrádání zkratky, která by ohrozila celkovou přehlednost systému.

Tento princip je obzvláště důležitý při navrhování API, datových formátů nebo stylistických pokynů ve velkém týmu, kde každá výjimka představuje výzvu. extra kognitivní zátěž pro všechny.

9. Ačkoli praktičnost vítězí nad čistotou

Tyto dva aforismy (pravidla a praktičnost) se vzájemně vyvažují. Na jedné straně je vyžadována důslednost; na druhé straně se uznává, že v reálném životě Nemůžeme být vždy úplně „čistí“ V designu jsou někdy pragmatické zkratky nezbytné pro dodržení termínů, přizpůsobení se omezením prostředí nebo usnadnění přijetí řešení.

Klíčem je nenechat se unést: praktičnost může ospravedlnit pragmatické zkratky pro dodržení termínůAle to by nemělo být výmluvou pro přijetí jakékoli nekvalitní práce. Typickým příkladem v Pythonu je použití stručných konstrukcí, které ve skutečnosti vylepšují kód, aniž by se uchylovalo k „černé magii“, kterou je třeba rozluštit.

V hypotetickém Zen C by se to projevilo v rozhodnutích, jako je akceptovat určité použití maker nebo specifických optimalizací kompilátor, když skutečně zlepšují výkon, aniž by kód byl nesrozumitelný.

10. Chyby by se nikdy neměly ignorovat.

Tato směrnice se zabývá ošetřením výjimek a chyb. Blokové konstrukce try/except zcela obecné, které prostě dělá pass Jsou jistým receptem na těžko laditelné problémy: něco se pokazí, nikdo si toho nevšimne a zdánlivě náhodné chování se objeví o měsíce později.

Zen doporučuje, aby s výjimkou případů velmi úmyslného rozhodnutí byly chyby viditelné: aby byly zachyceny pouze zamýšlené typy, aby byly zaznamenány v protokolyŽe posílat jasné zprávy nebo dokonce zastavit provádění, pokud systém neví, jak se obnovit.

V jazyce C. systematicky ignoruje návratové kódy nebo nekontroluje nulové ukazatele Je to zaručený způsob, jak proměnit údržbu v noční můru.

11. Pokud nebyli výslovně umlčeni

Stejně jako u jiných pravidel i zde hraje roli nuance. Existují situace, kdy víte o konkrétní chybě, prostudovali jste si její důsledky a rozhodnete se, že Není to kritické, ani to, že máte kontrolovaný způsob jednáníV takových případech může být jeho výslovné umlčení rozumné.

Typickým příkladem by bylo zachytit ValueError konkrétně a napsat ladicí zprávu s uvedením, že byla správně zpracovánaaniž by se výjimka dále rozšiřovala. Klíčové však je, aby se jednalo o vědomé a zdokumentované rozhodnutí, nikoli o způsob, jak zakrýt problémy.

V jazyce C by ekvivalent byl spravovat známý chybový kód vrácením zdokumentované výchozí hodnoty, v případě potřeby zaznamená událost a pouze v tomto kontextu ignoruje selhání, aniž by došlo k pádu aplikace.

12. Když čelíte nejasnostem, odmítněte pokušení hádat.

Tento aforismus zdůrazňuje velmi častou past: mentální vyplňování mezer, když jsou požadavky, design nebo dokonce samotný kód nejasné. Zen se zastává... Nevymýšlejte si významy tam, kde žádné nejsou.Pokud je něco nejednoznačné, je nejlepší vynutit si explicitní rozhodnutí.

V kódu se to promítá do názvů funkcí, které přesně vysvětlují, co dělají, komentářů, které objasňují důležité předpoklady, a co je nejdůležitější, testy, které definují očekávané chováníPokud není známo, co se má stát, kód skončí jako „hádání“ a téměř jistě bude chybný.

Když se tento princip aplikuje na potenciálního Zen C, stává se neustálou připomínkou: Nepředpokládejte, že kompilátor, platforma nebo standardní knihovna udělají to, co očekáváte. aniž by to bylo ověřeno v dokumentaci nebo v konkrétních testech.

13. Měl by existovat pouze jeden zřejmý způsob, jak to udělat

Tento princip je téměř jádrem identity Pythonu. Na rozdíl od mott, jako je Perlovo („Existuje více než jeden způsob, jak to udělat“), se Python snaží zajistit, aby pro daný úkol existuje jasně preferovaná cestaTo zjednodušuje učení a zvyšuje konzistenci kódu od různých lidí.

Klasickým příkladem je iterace nad sekvencemi. V Pythonu je prosazován velmi specifický přístup: for elemento in secuencia:Místo vynucování ručního indexování, s výjimkou případů, kdy je to nutné, se díky tomu smyčky čtení téměř zjednodušují.

Pro C by se tento duch mohl promítnout do přijetí na úrovni týmu, Standardní vzory pro opakující se operace: běžný způsob procházení polí, správy paměti nebo ošetřování chyb, místo aby si každý vývojář vymýšlel vlastní styl.

14. I když se tato metoda nemusí zpočátku zdát zřejmá (pokud nejste Holanďan)

Tento aforismus přidává mrknutí oka: preferovaný způsob není vždy na první pohled zřejmý. Často je potřeba seznámit se s jazykem, jeho knihovnami a ekosystémem, aby se tento „zřejmý způsob“ začal zdát přirozený.

Zmínka o Holanďanech je přímým odkazem na Guida van Rossuma, tvůrce Pythonu, který je Holanďanem. Pro něj může být mnoho designových rozhodnutí intuitivních, protože přesně ví, co zamýšlel; u ostatních je potřeba více zkušeností. období přizpůsobení se a učení.

Něco podobného by se stalo v jakémkoli neformálním „zenovém C“: co se zdá být zřejmé jazykovým veteránům (jak používat ukazatele, jak organizovat hlavičky, jak strukturovat projekt), může být pro někoho, kdo je v daném oboru nováčkem, velmi nejasné.

15. Teď je lepší než kdy dřív, i když nikdy není často lepší než právě teď.

Tyto dva aforismy hovoří o prioritách a načasování. Na jedné straně nás povzbuzují, abychom neupadli do paralýzy analýzy: Je lepší dosáhnout rozumného pokroku, než nedělat nic. Čekání na dokonalý návrh, který nikdy nedorazí. Na druhou stranu slouží jako připomínka toho, že spěchat se změnami bez rozmyslu může způsobit ještě horší problémy.

V kódu se to promítá do Nalezení rovnováhy mezi puštěním se do práce a neimprovizací při strukturálních změnách bez přemýšleníOdkládání určitých kritických úkolů na neurčito je obvykle špatný nápad, ale neustálé přerušování toho, co děláte, abyste se chytili každého nového nápadu, také nepomáhá.

Ideální přístup je obvykle považovat vývoj systému za iterativní proces: zavedení měřených změn a vyhodnocení jejich dopaduUpřesněte… a veďte si jasný seznam úkolů, abyste důležité záležitosti nenechávali „navždy“.

16. Pokud je implementace obtížně vysvětlitelná, je to špatný nápad.

Pokud potřebujete složitý odstavec, který vysvětluje, jak nějaký kód funguje, problém pravděpodobně není ve vašich komunikačních dovednostech, ale v samotném návrhu. Tento aforismus doporučuje používat vysvětlení jako test stavu návrhu.

Pokud je implementace tak složitá, že je těžké ji popsat jednoduše, obvykle to znamená, že existují příliš mnoho smíšených povinnostíŠpatně definované závislosti nebo neupřesněná rozhodnutí jsou známkou toho, že je vhodné provést refaktoring před přijetím tohoto přístupu.

Toto kritérium je velmi užitečné jak v Pythonu, tak v jazyce C: Pokud nejste schopni v několika větách vysvětlit, co funkce nebo modul děláObvykle je prostor pro strukturální vylepšení.

17. Pokud je implementace snadno vysvětlitelná, může to být dobrý nápad.

Rubovou stranou předchozího bodu je, že když dokážete řešení popsat jasně, stručně a přímočarě, pravděpodobně jste na správné cestě. To sice nezaručuje, že je nápad dokonalý, ale je to dobré znamení, že jste na správné cestě. složitost je pod kontrolou.

Tento princip se velmi dobře propojuje s praktikami, jako je „technika gumové kachničky“: hlasité vysvětlování, co váš kód dělá, jiné osobě (nebo neživému objektu), pomáhá odhalit nesrovnalosti a potvrdit, že je něco dobře promyšlené.

V týmovém kontextu, pokud kterýkoli člen týmu po krátkém vysvětlení rychle pochopí, co daný kód dělá, je mnohem snazší tuto část systému kontrolovat, udržovat a vyvíjet.

18. Jmenné prostory jsou skvělý nápad: pojďme jich dělat víc

Poslední aforismus zdůrazňuje důležitost jmenných prostorů jako nástroje pro organizaci kódu a předcházení kolizím. V Pythonu poskytují moduly, balíčky, třídy a funkce různé úrovně organizace. zapouzdření a oddělení odpovědností.

Konzistentní používání jmenných prostorů umožňuje existenci identifikátorů se stejným názvem v různých kontextech bez konfliktů a pomáhá seskupovat související prvky pod jeden logický deštník. Rozšíření používání těchto mechanismů často vede k modulárnějším architekturám.

V jazyce C, kde je systém jmenných prostorů mnohem rudimentárnější, se tato myšlenka promítá do konvencí pojmenování, strukturování podle hlavičkových a zdrojových souborů a disciplinovaného používání static a předpony, aby se zabránilo kolizím. Rozumné „zenové C“ by vybízelo zacházet s každým modulem jako s malým, dobře definovaným jmenným prostorem.

Překlady do španělštiny a kulturní nuance

V průběhu let bylo navrženo několik překladů těchto aforismů do španělštiny. Některé volí variantu „Krásná je lepší než ošklivá“, jiné „Krásná je lepší než ošklivá“ atd. Všechny se snaží zachovat ducha originálu, i když se nevyhnutelně objevují určité variace. stylistické nuance a výběr slovní zásoby charakteristika překladatele.

Ve španělštině je běžné hovořit o kódu jako o „hezkém“, „čitelném“ nebo „jasném“ a o vyhněte se „chybám“ nebo „rychlým záplatám“Stejná myšlenka je základem původního zenu, který mísí vážný tón s nádechem humoru, zejména v aforismu, který zmiňuje, že zřejmá cesta nemusí být zpočátku taková, „pokud nejste Holanďan“.

Tyto překlady také slouží k tomu, aby byl text srozumitelnější pro lidi, kteří neovládají plynnou angličtinu, aniž by se ztrácela ze zřetele skutečnost, že dané zásady jsou použitelné. pro jakýkoli jazyk a jakoukoli vývojářskou komunitumimo ekosystém Pythonu.

Je Zen Pythonu vtip, nebo posvátné pravidlo?

V rámci samotné komunity Pythonu probíhá debata o přesném statusu Zen. Na jedné straně jej mnoho formálních dokumentů (PEP) uvádí jako motivace nebo zdůvodnění rozhodnutía v e-mailových seznamech klíčových vývojářů se používá jako argument pro nebo proti konkrétním návrhům.

Na druhou stranu někteří poskytovatelé údržby poukázali na to, že použít zenovou frázi jako zbraň („Toto porušuje zen, proto je to špatné“) nedává vždy smysl. Existují dokonce i PEP, kteří poznamenávají, že určité aforismy byly kdysi interpretovány jako kritika samotného jazyka v jeho počátcích a neměly by být brány doslova.

Realita je taková, že Zen funguje nejlépe jako kulturní kompas a zdroj inspirace což je striktní pravidlo návrhu. Python s časZahrnuje funkce (jako je přiřazování ve výrazech nebo porovnávání vzorů), které někteří považují za „složitější“ nebo méně v souladu s původní jednoduchostí, a přesto byly přijaty pro svou užitečnost.

V tomto smyslu by uvažování o „Zen C“ mělo spíše společného s zachytit obecné principy které pomáhají psát lepší kód v jazyce C, aniž by se z nich stávaly nepružné zákony blokující jakýkoli vývoj stylu nebo nástrojů.

Tato sbírka aforismů, překladů, příkladů a diskusí tvoří jakousi myšlenkovou mapu toho, jak chápeme „dobrý kód“: čitelný, co nejjednodušší, explicitní ve svých záměrech a promyšleně strukturovaný. Ať už v Pythonu, C nebo jakémkoli jiném jazyce, Přijetí této filozofie často rozhoduje o tom, zda je program obtížný, nebo příjemný na práci..