The Invent with Python Blog

The Zen of Python by Tim Peters ovat 20 ohjetta Python-kielen suunnitteluun. Python-koodisi ei välttämättä tarvitse noudattaa näitä ohjeita, mutta ne on hyvä pitää mielessä. Pythonin Zen on pääsiäismuna eli piilovitsi, joka ilmestyy, jos juokset 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!

huomautus: mystisesti vain 19 ohjeista on kirjoitettu ylös. Guido van Rosumin kerrotaan sanoneen, että puuttuva 20.aforismi on ”jokin outo Tim Peters in-vitsi.”

loppujen lopuksi nämä suuntaviivat ovat mielipiteitä, joiden puolesta tai vastaan voi argumentoida. Kuten kaikki hyvät moraalikoodit, ne ovat toisinaan ristiriidassa keskenään tarjotakseen mahdollisimman paljon joustavuutta. Tässä oma tulkintani näistä aforismeista:

kaunis on parempi kuin ruma.

ohjelmoijat kirjoittavat koodia usein nopeasti huoletta luettavuudesta. Vaikka koodin ei tarvitse olla luettavissa, itse Python-kielen koodin tulee olla harkittua, johdonmukaista ja iloa käyttää. Jokaisen käsikirjoituksen ei tietenkään tarvitse olla kaunis, ja kauneus on subjektiivista, mutta suuri osa Pythonin suosiosta johtuu siitä, että sitä on niin helppo työstää.

eksplisiittinen on parempi kuin implisiittinen.

”tämä aforismi on itsestään selvä”, se olisi kauhea selitys mille tahansa aforismille. Samoin on parempi, että koodi on monisanainen ja täsmällinen. Kannattaa välttää piilottamasta koodin toiminnallisuutta epämääräisten kieliominaisuuksien taakse, joiden ymmärtäminen vaatii perehtyneisyyttä.

yksinkertainen on parempi kuin monimutkainen. Monimutkainen on parempi kuin monimutkainen.

nämä kaksi aforismia muistuttavat, että mitä tahansa voidaan rakentaa yksinkertaisilla tai monimutkaisilla tekniikoilla. Yksinkertaisessa ongelmassa, kuten linnunpöntön rakentamisessa, yksinkertainen ratkaisu on parempi. Dieseljunan Moottorin rakentaminen taas on monimutkainen ongelma, joka vaatii monimutkaisia tekniikoita. Vaikka dieseljunan Moottorin voisi teknisesti tehdä linnunpönttötekniikalla, päädyttäisiin todennäköisesti monimutkaiseen, Rube Goldbergin suunnittelemaan linnunpönttöjen osiin, jotka eivät olisi ihanteellinen ratkaisu. Suosi yksinkertaisuutta monimutkaisuuden sijaan, mutta tunne yksinkertaisuuden rajat.

litteä on parempi kuin sisäkkäinen.

ohjelmoijat järjestelevät mielellään asioita luokkiin, erityisesti luokkiin, jotka sisältävät alaluokkia, jotka sisältävät muita alaluokkia. Nämä hierarkiat eivät useinkaan lisää organisaatiota vaan byrokratiaa. Se on ok olla koodi vain yhdessä ylimmän kerroksen moduulissa tai luokassa sen sijaan jakaa useisiin alimodules tai alaluokkien. Jos teet paketteja ja moduuleja, jotka vaativat koodia, kuten import spam.eggs.bacon.ham.foo.bar, teet koodistasi liian monimutkaisen.

harva on parempi kuin tiheä.

ohjelmoijat haluavat usein ahtaa mahdollisimman paljon toiminnallisuutta mahdollisimman pieneen koodiin, kuten one-linerit kuten seuraavat: 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.

luettavuus ratkaisee.

vaikka strcmp() voi ilmeisesti tarkoittaa ”string compare” – funktiota jollekulle, joka on ohjelmoinut C-kielellä 1970-luvulta lähtien, nykytietokoneissa on tarpeeksi muistia, jotta funktion koko nimi voidaan kirjoittaa ulos. Älä pudota vokaaleja nimistäsi tai kirjoita liian terseää koodia. Koodia luetaan useammin kuin sitä kirjoitetaan, joten eksplisiittinen, luettava koodi on tärkeämpi kuin tiivistetty, paperiton koodi.

erikoistapaukset eivät ole tarpeeksi erikoisia sääntöjen rikkomiseen. Käytännöllisyys tosin voittaa puhtauden.

nämä kaksi aforismia, jotka tulevat joukkona, ovat ristiriidassa keskenään. Ohjelmointi on täynnä ”parhaita käytäntöjä”, joihin ohjelmoijien tulisi pyrkiä koodissaan. Näiden käytäntöjen kiertäminen nopeaa hakkerointia varten voi olla houkuttelevaa, mutta se voi johtaa epäjohdonmukaisen, lukukelvottoman koodin rotanpesään. Sääntöjen noudattamiseen taipuminen voi kuitenkin johtaa erittäin abstraktiin, lukukelvottomaan koodiin. Java-ohjelmointikielen yritys sovittaa kaikki koodi olio-orientoituneeseen paradigmaansa johtaa usein siihen, että pienellekin ohjelmalle löytyy paljon boilerplate-koodia. Näiden kahden aforismin välisen rajan kulkeminen helpottuu kokemuksen myötä. Ja aikanaan, et vain oppia sääntöjä, mutta myös oppia, milloin rikkoa niitä.

virheet eivät saa koskaan mennä ohi äänettömästi. Ellei sitä hiljennetä.

vaikka ohjelmoijat usein sivuuttavat Virheilmoitukset, ei se tarkoita, että ohjelman pitäisi lopettaa niiden lähettäminen. Äänettömiä virheitä voi tapahtua, kun funktiot palauttavat virhekoodeja tai None poikkeusten nostamisen sijaan. Nämä kaksi aforismia kertovat, että ohjelman on parempi fail fast ja kaatua kuin vaientaa virhe ja jatkaa ohjelman pyörittämistä. Vikoja, jotka väistämättä tapahtuvat myöhemmin, on vaikeampi debug, koska ne ovat kaukana alkuperäisestä syystä. Vaikka voit aina valita nimenomaisesti sivuuttaa virheet ohjelmien aiheuttaa, vain olla varma olet tekemässä tietoinen valinta tehdä niin.

monitulkintaisuuden uhatessa kieltäydy kiusauksesta arvata.

tietokoneet ovat tehneet ihmisistä taikauskoisia: manataksemme demonit tietokoneissamme suoritamme Pyhän rituaalin sammuttaa ne ja sitten jatkaa. Tämä korjaa arvoitukselliset ongelmat. Tietokoneet eivät kuitenkaan ole taikuutta. Jos koodi ei toimi, on syy ja vain huolellinen, kriittinen ajattelu ratkaisee sen. Kieltäydy kiusauksesta yrittää sokeasti ratkaisuja, kunnes jokin näyttää toimivan; usein olet vain peitellyt ongelman etkä ratkaissut sitä.

pitäisi olla yksi—ja mielellään vain yksi—ilmeinen tapa tehdä se.

tämä on broadside vastaan Perl-ohjelmointikielen motto, ”There’ s more than one way to do it!”On käynyt ilmi, että se, että on kolme tai neljä eri tapaa kirjoittaa koodia, joka tekee saman asian, on kaksiteräinen miekka: sinulla on joustavuutta siinä, miten kirjoitat koodia, mutta nyt sinun on opittava kaikki mahdolliset tavat, joilla se olisi voitu kirjoittaa, jotta voit lukea sitä. Tämä joustavuus ei kannata 3x tai 4x vaivaa tarvitaan oppia ohjelmointikielen.

tosin se ei välttämättä ole aluksi itsestään selvää, ellei ole Hollantilainen.

tämä rivi on vitsi. Pythonin luoja ja BDFL (hyväntahtoinen diktaattori elämälle) Guido van Rossum on hollantilainen. Tämä aforismikaan ei kuitenkaan estänyt Pythonia sisällyttämästä tekstiin kolmea eri tapaa muotoilla merkkijonoja.

nyt on parempi kuin ei milloinkaan. Vaikka koskaan on usein parempi kuin * right * nyt.

nämä kaksi aforismia kertovat meille, että koodi, joka roikkuu tai jää kiinni äärettömiin silmukoihin, on selvästi pahempi kuin koodi, joka ei. on kuitenkin melko varmasti parempi odottaa ohjelmansa päättymistä kuin saada se valmiiksi liian aikaisin virheellisin tuloksin.

jos toteutusta on vaikea selittää, se on huono idea. Jos toteutus on helppo selittää, se voi olla hyvä idea.

Python pyrkii tekemään ohjelmoijan työn helpommaksi tietokoneen sijaan, jotta ohjelma toimisi nopeammin. Ja ohjelmien täytyy olla ymmärrettäviä paitsi ohjelmoijan, joka kirjoitti sen, mutta myös muiden ohjelmoijien, jotka ylläpitävät koodia. Nämä kaksi aforismia muistuttavat meitä siitä, että jos ”korkean suorituskyvyn” koodi on niin monimutkainen, että se on mahdotonta ohjelmoijille ymmärtää ja debug, niin se on huono koodi. Mutta valitettavasti, vain koska se on helppo selittää ohjelman koodi joku muu ei tarkoita, että se ei ole huono koodi. Ohjelmointi on vaikeaa.

nimiavaruudet ovat yksi tööttäilevä loistava idea-tehdään niitä lisää!

nimiavaruudet (ja myös globaalit ja paikalliset laajuudet) ovat avainasemassa, kun estetään yhden moduulin tai alueen nimien ristiriitaisuus toisen moduulin nimien kanssa. Mutta myös muistaa, että tasainen on parempi kuin sisäkkäinen: niin suuri kuin ne ovat, nimiavaruudet tulisi tehdä vain estää nimeäminen ristiriitoja, eikä lisätä tarpeetonta luokittelua.

kuten kaikki ohjelmointia koskevat mielipiteet, myös täällä kirjoittamani mielipiteet voidaan perustella tai ne voivat yksinkertaisesti olla merkityksettömiä tilanteesi kannalta. Riitely siitä, miten koodi pitäisi kirjoittaa, on harvoin niin tuottavaa kuin luulet. (Paitsi jos kirjoitat kokonaisen kirjan täynnä ohjelmointipuheita.)