Invent s Pythonem Blog

Zen Pythonu Tim Peters je 20 pokynů pro návrh jazyka Python. Váš kód Pythonu nemusí nutně dodržovat tyto pokyny, ale je dobré mít na paměti. Zen Pythonu je velikonoční vajíčko nebo skrytý vtip, který se objeví, pokud spustíte 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!

poznámka: záhadně je zapsáno pouze 19 pokynů. Guido van Rosum údajně řekl, že chybějící 20. aforismus je “ nějaký bizarní vtip Tim Peters.“

nakonec jsou tyto pokyny názory, které lze argumentovat pro nebo proti. Stejně jako všechny dobré sady morálních kodexů, někdy si odporují, aby poskytovaly co největší flexibilitu. Zde je můj vlastní výklad těchto aforismů:

krásný je lepší než ošklivý.

programátoři často píší kód rychle bez obav o čitelnost. Zatímco kód nemusí být čitelný, kód samotného jazyka Python musí být promyšlený, konzistentní a radost z použití. Samozřejmě, ne každý skript musí být krásný a krása je subjektivní,ale velká část popularity Pythonu je výsledkem tak snadné práce.

explicitní je lepší než implicitní.

„tento aforismus je samozřejmý“, což by bylo hrozné vysvětlení pro jakýkoli aforismus. Stejně tak je lepší, aby kód byl podrobný a explicitní. Měli byste se vyhnout skrývá kód funkce za obskurní jazyk funkce, které vyžadují znalosti, aby plně pochopit.

jednoduché je lepší než složité. Komplex je lepší než komplikovaný.

tyto dva aforismy nám připomínají, že budování všeho lze provést pomocí jednoduchých nebo složitých technik. S jednoduchým problémem, jako je stavba ptačí budky, je jednoduché řešení lepší. Na druhé straně je stavba dieselového vlakového motoru složitým problémem, který vyžaduje složité techniky. I kdybyste mohli technicky vyrobit dieselový vlakový motor pomocí technik birdhouse, pravděpodobně byste skončili s komplikovaným uspořádáním částí birdhouse Rube Goldberg, které by nebylo ideálním řešením. Preferujte jednoduchost před složitostí, ale znáte hranice jednoduchosti.

byt je lepší než vnořený.

programátoři rádi organizují věci do kategorií, zejména do kategorií, které obsahují podkategorie, které obsahují další podkategorie. Tyto hierarchie často nepřidávají organizaci tolik, jako přidávají byrokracii. Je v pořádku mít kód pouze v jednom modulu nebo třídě nejvyšší vrstvy namísto rozdělení na více submodulů nebo podtříd. Pokud vytváříte balíčky a moduly, které vyžadují kód jako import spam.eggs.bacon.ham.foo.bar, pak váš kód příliš komplikujete.

řídká je lepší než hustá.

Programátoři často chtěli nacpat co nejvíce funkcí do co malý kód, jak je to možné, jako je one-vložky, jako je následující: 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.

Čitelnost se počítá.

, Zatímco strcmp() může samozřejmě znamenat „řetězec porovnat“ funkce, aby někdo, kdo byl programování v C od roku 1970, moderní počítače mají dost paměti psát plný název funkce. Nespouštějte samohlásky ze svých jmen ani nepište příliš přísný kód. Kód se čte častěji, než je napsáno, takže explicitní, čitelný kód je důležitější než strohý, nezdokumentovaný kód.

zvláštní případy nejsou natolik zvláštní, aby porušily pravidla. Ačkoli praktičnost překonává čistotu.

tyto dva aforismy, které přicházejí jako soubor, si navzájem odporují. Programování je plné „osvědčených postupů“, o které by se programátoři měli ve svém kódu snažit. Obcházení těchto postupů pro rychlý hack může být lákavé, ale může vést k krysímu hnízdě nekonzistentní, nečitelný kód. Nicméně, ohýbání dozadu, aby se dodržovala pravidla, může mít za následek vysoce abstraktní, nečitelný kód. Pokus programovacího jazyka Java přizpůsobit veškerý kód objektově orientovanému paradigmatu má často za následek spoustu kódu boilerplate i pro nejmenší program. Chůze hranice mezi těmito dvěma aforismy se stává snadnější se zkušenostmi. A časem se nejen naučíte pravidla, ale také se naučíte, kdy je porušit.

chyby by nikdy neměly projít tiše. Pokud není výslovně umlčen.

jen proto, že programátoři často ignorují chybové zprávy, neznamená, že by je program měl přestat emitovat. Tiché chyby se mohou stát, když funkce vrátí chybové kódy nebo None namísto zvyšování výjimek. Tyto dva aforismy nám říkají, že je lepší, aby program fail fast a havaroval, než umlčet chybu a pokračovat v běhu programu. Chyby, které se nevyhnutelně stanou později, budou těžší ladit, protože jsou daleko od původní příčiny. I když se můžete vždy rozhodnout explicitně ignorovat chyby, které vaše programy způsobují, ujistěte se, že děláte vědomou volbu.

tváří v tvář nejednoznačnosti odmítněte pokušení hádat.

počítače učinily lidi pověrčivými: abychom vymítali démony v našich počítačích, provádíme posvátný rituál jejich vypnutí a zapnutí. Pravděpodobně to vyřeší jakýkoli záhadný problém. Počítače však nejsou magické. Pokud váš kód nefunguje, existuje důvod a pouze pečlivé, kritické myšlení to vyřeší. Odmítněte pokušení slepě vyzkoušet řešení, dokud se zdá, že něco funguje; často jste problém pouze maskovali, než jste ho vyřešili.

měl by existovat jeden—a nejlépe jediný—zřejmý způsob, jak to udělat.

toto je široká stránka proti mottu programovacího jazyka Perl: „existuje více než jeden způsob, jak to udělat!“Ukazuje se, že mít tři nebo čtyři různé způsoby, jak psát kód, který dělá to samé, je dvousečný meč: máte flexibilitu v tom, jak psát kód, ale nyní musíte se naučit každý možný způsob, jak by to mohlo být napsané, aby si ji přečíst. Tato flexibilita nestojí za 3x nebo 4x úsilí potřebné k učení programovacího jazyka.

i když tento způsob nemusí být na první pohled zřejmý, pokud nejste Holanďané.

tento řádek je vtip. Guido van Rossum, tvůrce a BDFL (benevolentní diktátor pro život) Pythonu, je Holanďan. Ani tento aforismus však nebránil Pythonu v začlenění tří různých způsobů formátování řetězců.

nyní je lepší než nikdy. I když nikdy není často lepší než * právě * teď.

Tyto dva aforismy nám řekli, že kód, který visí nebo je chycen v nekonečné smyčky je samozřejmě horší, než kód, který nefunguje. Nicméně, to je téměř jistě lepší počkat na svůj program dokončit, než mít to dokončit příliš brzy s nesprávným výsledkům.

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

Python se snaží usnadnit práci programátora spíše než přizpůsobit počítač, takže program běží rychleji. A programy musí být srozumitelné nejen programátorem, který je napsal, ale také dalšími programátory, kteří kód udržují. Tyto dva aforismy nám připomínají, že pokud je“ vysoce výkonný “ kód tak komplikovaný, že programátoři nemohou pochopit a ladit, pak je to špatný kód. Ale bohužel, jen proto, že je snadné vysvětlit kód programu někomu jinému, neznamená, že to není špatný kód. Programování je těžké.

Jmenné prostory jsou jeden skvělý nápad-udělejme jich víc!

jmenné prostory (a také globální a lokální obory) jsou klíčové pro prevenci jména v jednom modulu nebo rozsah v konfliktu s názvy v jiném. Ale také si pamatujte, že flat je lepší než vnořené: tak velké, jak jsou, jmenné prostory by měly být vytvořeny pouze proto, aby se zabránilo konfliktům pojmenování, a nepřidávat zbytečnou kategorizaci.

stejně jako všechny názory na programování, ty, které jsem zde napsal, lze argumentovat proti nebo mohou být pro vaši situaci jednoduše irelevantní. Dohadovat se o tom, jak by měl být kód napsán, je zřídka tak produktivní, jak si myslíte. (Pokud nepíšete celou knihu plnou programových názorů.)