The Invent with Python Blog

a Zen of Python által Tim Peters vannak 20 iránymutatások a design a Python nyelvet. A Python kódjának nem feltétlenül kell követnie ezeket az irányelveket, de ezeket jó szem előtt tartani. A Python Zen egy húsvéti tojás, vagy rejtett vicc, amely akkor jelenik meg, ha fut 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!

megjegyzés: rejtélyes módon az iránymutatások közül csak 19 van leírva. Guido van Rosum állítólag azt mondta, hogy a hiányzó 20.Aforizma “valami furcsa Tim Peters vicc.”

végül ezek az irányelvek olyan vélemények, amelyek mellett vagy ellen lehet érvelni. Mint minden jó erkölcsi kódex, néha ellentmondanak maguknak, hogy a legnagyobb rugalmasságot biztosítsák. Itt van a saját értelmezésem ezekről az aforizmákról:

a szép jobb, mint a csúnya.

a programozók gyakran gyorsan írnak kódot, anélkül, hogy aggódnának az olvashatóság miatt. Bár a kódnak nem kell olvashatónak lennie, magának a Python nyelvnek a kódját át kell gondolni, következetesnek kell lennie, és örömmel kell használni. Természetesen nem minden forgatókönyvnek kell szépnek lennie, és a szépség szubjektív, de a Python népszerűségének nagy része annak köszönhető, hogy ilyen könnyű vele dolgozni.

az Explicit jobb, mint az implicit.

“ez az aforizma magától értetődő”, ez szörnyű magyarázat lenne minden aforizmusra. Hasonlóképpen jobb, ha a kód bőbeszédű és explicit. Kerülje a kód funkcionalitásának elrejtését olyan homályos nyelvi funkciók mögött, amelyek teljes megértéséhez ismeretre van szükség.

az egyszerű jobb, mint a komplex. A komplex jobb, mint a bonyolult.

ez a két Aforizma emlékeztet bennünket arra, hogy bármit meg lehet építeni egyszerű vagy összetett technikákkal. Egy egyszerű probléma, például egy madárház építése esetén jobb egy egyszerű megoldás. A dízel vonatmotor építése viszont összetett probléma, amely összetett technikákat igényel. Még akkor is, ha technikailag, hogy egy dízel vonat motor segítségével birdhouse technikák, akkor valószínűleg a végén egy bonyolult, Rube Goldberg elrendezése birdhouse alkatrészek, hogy nem lenne ideális megoldás. Inkább az egyszerűséget, mint a bonyolultságot részesítse előnyben, de ismerje az egyszerűség határait.

a lapos jobb, mint a beágyazott.

a programozók szeretik kategóriákba rendezni a dolgokat, különösen olyan kategóriákba, amelyek alkategóriákat tartalmaznak, amelyek más alkategóriákat tartalmaznak. Ezek a hierarchiák gyakran nem annyira növelik a szervezetet, mint a bürokráciát. Rendben van, ha a kód csak egy felső rétegű modulban vagy osztályban van, ahelyett, hogy több almodulra vagy alosztályra osztaná fel. Ha olyan csomagokat és modulokat készítesz, amelyek olyan kódot igényelnek, mint a import spam.eggs.bacon.ham.foo.bar, akkor túl bonyolulttá teszed a kódot.

a ritka jobb, mint a sűrű.

a programozók gyakran szeretnek annyi funkcionalitást belezsúfolni a lehető legkevesebb kódba, mint például az alábbiak: 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.

az olvashatóság számít.

míg a strcmp() nyilvánvalóan a “string compare” függvényt jelentheti valakinek, aki az 1970-es évek óta programoz C-ben, a modern számítógépek elegendő memóriával rendelkeznek a teljes funkciónév kiírásához. Ne ejtsen magánhangzókat a nevéből, vagy ne írjon túl szűk kódot. A kódot gyakrabban olvassák, mint írják, így az explicit, olvasható kód fontosabb, mint a tömör, dokumentálatlan kód.

a különleges esetek nem elég különlegesek ahhoz, hogy megszegjék a szabályokat. Bár a gyakorlatiasság legyőzi a tisztaságot.

ez a két Aforizma, amelyek halmazként jönnek létre, ellentmondanak egymásnak. A programozás tele van” legjobb gyakorlatokkal”, amelyekre a programozóknak törekedniük kell a kódjukban. Lábazati ezek a gyakorlatok egy gyors hack lehet csábító, de vezethet a patkányfészek következetlen, olvashatatlan kódot. A szabályok betartása érdekében azonban hátrafelé hajolva rendkívül elvont, olvashatatlan kódot eredményezhet. A Java programozási nyelv azon kísérlete, hogy az összes kódot az objektumorientált paradigmájához igazítsa, gyakran sok kazánplate kódot eredményez még a legkisebb program számára is. A két Aforizma közötti vonal járása a tapasztalatokkal könnyebbé válik. És idővel, akkor nem csak tanulni a szabályokat, de azt is megtanulják, mikor kell megtörni őket.

a hibák soha nem haladhatnak csendben. Kivéve, ha kifejezetten elhallgattatják.

csak azért, mert a programozók gyakran figyelmen kívül hagyják a hibaüzeneteket, még nem jelenti azt, hogy a programnak abba kell hagynia a kibocsátásukat. Csendes hibák fordulhatnak elő, ha a függvények hibakódokat vagy None – et adnak vissza a kivételek növelése helyett. Ez a két Aforizma azt mondja nekünk, hogy jobb, ha EGY program fail fast és összeomlik, mint elhallgattatni a hibát, és folytatni a program futtatását. A hibákat, amelyek elkerülhetetlenül később történnek, nehezebb lesz hibakeresni, mivel messze vannak az eredeti októl. Bár mindig dönthet úgy, hogy kifejezetten figyelmen kívül hagyja a programok által okozott hibákat, csak győződjön meg róla, hogy tudatosan választja ezt.

a kétértelműség ellenére utasítsa el a kísértést, hogy kitaláljon.

a számítógépek babonássá tették az embereket: a számítógépeinkben lévő démonok kiűzéséhez elvégezzük azt a Szent rituálét, hogy kikapcsoljuk, majd bekapcsoljuk őket. Állítólag ez megoldja a titokzatos problémákat. A számítógépek azonban nem varázslatosak. Ha a kód nem működik, annak oka van, és csak óvatos, kritikus gondolkodás oldja meg. Utasítsa el a kísértést, hogy vakon próbálja meg a megoldásokat, amíg valami úgy tűnik, hogy működik; gyakran csak elfedte a problémát, nem pedig megoldotta.

ennek egy—lehetőleg csak egy—nyilvánvaló módnak kell lennie.

ez egy széles oldal a Perl programozási nyelv mottójával szemben: “több módja is van!”Kiderült, hogy a kód írásának három vagy négy különböző módja, amely ugyanazt csinálja, kétélű kard: rugalmasan írhatja a kódot, de most minden lehetséges módon meg kell tanulnia, hogy elolvassa. Ez a rugalmasság nem éri meg a programozási nyelv megtanulásához szükséges 3x vagy 4x erőfeszítést.

bár ez az út először nem nyilvánvaló, hacsak nem holland vagy.

ez a sor egy vicc. Guido van Rossum, a Python alkotója és BDFL (jóindulatú diktátor az életért) Holland. Azonban még ez az aforizma sem akadályozta meg a Pythont abban, hogy a karakterláncok formázásának három különböző módját beépítse.

most jobb, mint soha. Bár a soha gyakran jobb, mint * most*.

ez a két Aforizma azt mondja nekünk, hogy a végtelen hurkokban lógó vagy elakadt kód nyilvánvalóan rosszabb, mint a nem kód. azonban szinte biztosan jobb megvárni a program befejezését, mint túl korán befejezni helytelen eredményekkel.

ha a megvalósítás nehéz megmagyarázni, ez egy rossz ötlet. Ha a megvalósítás könnyen megmagyarázható, akkor jó ötlet lehet.

a Python arra törekszik, hogy megkönnyítse a programozó munkáját, ahelyett, hogy befogadná a számítógépet, így a program gyorsabban fut. A programoknak érthetőnek kell lenniük nemcsak a programozó számára, aki írta, hanem más programozók számára is, akik fenntartják a kódot. Ez a két Aforizma arra emlékeztet bennünket, hogy ha a” nagy teljesítményű ” kód annyira bonyolult, hogy a programozók számára lehetetlen megérteni és hibakeresni, akkor rossz kód. De sajnos, csak azért, mert könnyű megmagyarázni EGY program kódját valakinek, még nem jelenti azt, hogy nem rossz kód. A programozás nehéz.

a névterek egy nagyszerű ötlet—csináljunk többet ezekből!

a névterek (valamint a globális és helyi hatókörök) kulcsfontosságúak ahhoz, hogy megakadályozzák az egyik modulban vagy hatókörben lévő nevek ütközését egy másikban lévő nevekkel. De ne feledje, hogy a lapos jobb, mint a beágyazott: bármennyire is nagyok, a névtereket csak a névkonfliktusok elkerülése érdekében kell elkészíteni, nem pedig felesleges kategorizálás hozzáadása érdekében.

mint minden vélemény a programozásról, az is, amit itt írtam, vitatható, vagy egyszerűen nem releváns a helyzeted szempontjából. Azon vitatkozni, hogy hogyan kell kódot írni, ritkán olyan produktív, mint gondolnád. (Hacsak nem írsz egy egész könyvet, tele programozási véleményekkel.)