inventa cu Python Blog

Zen Python de Tim Peters sunt 20 de linii directoare pentru proiectarea limbajului Python. Python nu trebuie neapărat să respecte aceste instrucțiuni, dar este bine să le țineți cont. Zen de Python este un ou de Paște, sau glumă ascunsă, care apare dacă executați 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!

notă: în mod misterios, doar 19 dintre liniile directoare sunt scrise. Guido van Rosum ar fi spus că al 20-lea aforism dispărut este „un bizar Tim Peters în glumă.”

în cele din urmă, aceste linii directoare sunt opinii care pot fi argumentate pentru sau împotriva. Ca toate seturile bune de coduri morale, uneori se contrazic pentru a oferi cea mai mare flexibilitate. Iată propria mea interpretare a acestor Aforisme:

frumos este mai bun decât urât.

programatorii scriu adesea Cod rapid, fără îngrijorare pentru lizibilitate. Deși codul nu trebuie să fie lizibil, codul limbajului Python în sine trebuie să fie gândit, consecvent și o bucurie de utilizat. Desigur, nu orice scenariu trebuie să fie frumos, iar frumusețea este subiectivă, dar o mare parte din popularitatea lui Python este rezultatul faptului că este atât de ușor de lucrat.

Explicit este mai bun decât implicit.

„acest aforism se explică de la sine”, aceasta ar fi o explicație teribilă pentru orice aforism. În mod similar, este mai bine ca Codul să fie detaliat și explicit. Ar trebui să evitați ascunderea funcționalității codului în spatele caracteristicilor obscure ale limbajului care necesită familiaritate pentru a înțelege pe deplin.

simplu este mai bun decât complex. Complexul este mai bun decât complicat.

aceste două Aforisme ne amintesc că construirea oricărui lucru se poate face folosind tehnici simple sau complexe. Cu o problemă simplă, cum ar fi construirea unei case de păsări, o soluție simplă este mai bună. Construirea unui motor de tren diesel, pe de altă parte, este o problemă complexă care necesită tehnici complexe. Chiar dacă ai putea face punct de vedere tehnic un motor de tren diesel folosind tehnici birdhouse, probabil că s-ar termina cu un aranjament complicat, Rube Goldberg de piese birdhouse, care nu ar fi o soluție ideală. Preferă simplitatea în locul complexității, dar cunoaște limitele simplității.

plat este mai bună decât imbricate.

programatorilor le place să organizeze lucrurile în categorii, în special categorii care conțin subcategorii care conțin alte sub-subcategorii. Aceste ierarhii adesea nu adaugă organizare atât de mult cât adaugă birocrație. Este în regulă să aveți cod într-un singur modul sau clasă de nivel superior, în loc să vă împărțiți în mai multe submodule sau subclase. Dacă creați pachete și module care necesită cod ca import spam.eggs.bacon.ham.foo.bar, atunci faceți codul prea complicat.

rar este mai bun decât dens.

programatorilor le place adesea să înghesuie cât mai multă funcționalitate în cât mai puțin cod posibil, cum ar fi one-liners, cum ar fi următoarele: 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.

lizibilitatea contează.

în timp ce strcmp() poate însemna în mod evident funcția „string compare” cu cineva care programează în C încă din anii 1970, computerele moderne au suficientă memorie pentru a scrie numele complet al funcției. Nu renunțați la vocale din numele dvs. și nu scrieți cod prea concis. Codul este citit mai des decât este scris, deci codul explicit și lizibil este mai important decât codul concis, nedocumentat.

cazurile speciale nu sunt suficient de speciale pentru a încălca regulile. Deși practicitatea bate puritatea.

aceste două aforisme, care vin ca un set, se contrazic reciproc. Programarea este plină de” cele mai bune practici ” pe care programatorii ar trebui să le depună eforturi în codul lor. Plinte aceste practici pentru un hack rapid poate fi tentant, dar poate duce la un cuib de șobolan de cod inconsistente, ilizibil. Cu toate acestea, îndoirea înapoi pentru a adera la reguli poate duce la un cod extrem de abstract, care nu poate fi citit. Încercarea limbajului de programare Java de a încadra tot codul în paradigma sa orientată pe obiecte duce adesea la o mulțime de cod de șabloane chiar și pentru cel mai mic program. Mersul pe linia dintre aceste două Aforisme devine mai ușor cu experiența. Și în timp, veți învăța nu numai regulile, dar, de asemenea, să învețe când să le încalce.

Erorile nu ar trebui să treacă niciodată în tăcere. Cu excepția cazului în care este redus la tăcere în mod explicit.

doar pentru că programatorii ignoră adesea mesajele de eroare nu înseamnă că programul ar trebui să înceteze să le emită. Erori silențioase se pot întâmpla atunci când funcțiile returnează coduri de eroare sau None în loc să ridice excepții. Aceste două Aforisme ne spun că este mai bine ca un program să fail fast și să se prăbușească decât să reducă la tăcere eroarea și să continue să ruleze programul. Bug-urile care se întâmplă inevitabil mai târziu vor fi mai greu de depanat, deoarece sunt departe de cauza inițială. Deși puteți alege întotdeauna să ignorați în mod explicit erorile pe care le provoacă programele dvs., asigurați-vă că faceți alegerea conștientă de a face acest lucru.

în fața ambiguității, refuză tentația de a ghici.

computerele i-au făcut pe oameni superstițioși: pentru a exorciza demonii din computerele noastre, îndeplinim ritualul sacru de a-i opri și apoi de a-i porni. Se presupune că acest lucru va rezolva orice problemă misterioasă. Cu toate acestea, computerele nu sunt magice. Dacă codul dvs. nu funcționează, există un motiv și numai gândirea critică atentă îl va rezolva. Refuzați tentația de a încerca orbește soluții până când ceva pare să funcționeze; de multe ori pur și simplu ați mascat problema, mai degrabă decât ați rezolvat-o.

ar trebui să existe o singură—și de preferință o singură—modalitate evidentă de a o face.

aceasta este o lovitură împotriva motto-ului limbajului de programare Perl, ” există mai multe moduri de a face acest lucru!”Se pare că a avea trei sau patru moduri diferite de a scrie cod care face același lucru este o sabie cu două tăișuri: ai flexibilitate în modul în care scrii cod, dar acum trebuie să înveți toate modurile posibile în care ar fi putut fi scris pentru a-l citi. Această flexibilitate nu merită efortul 3x sau 4x necesar pentru a învăța un limbaj de programare.

deși acest mod nu poate fi evident la început decât dacă sunteți olandez.

această linie este o glumă. Guido van Rossum, creatorul și BDFL (dictatorul binevoitor pentru viață) al lui Python, este olandez. Cu toate acestea, nici măcar acest aforism nu a împiedicat Python să încorporeze trei moduri diferite de formatare a șirurilor.

acum este mai bine decât niciodată. Deși niciodată nu este adesea mai bun decât * chiar* acum.

aceste două Aforisme ne spun că codul care atârnă sau este prins în bucle infinite este evident mai rău decât codul care nu. cu toate acestea, este aproape sigur mai bine să așteptați ca programul dvs. să se termine decât să îl terminați prea devreme cu rezultate incorecte.

dacă implementarea este greu de explicat, este o idee proastă. Dacă implementarea este ușor de explicat, poate fi o idee bună.

Python se străduiește să facă munca programatorului mai ușoară decât să găzduiască computerul, astfel încât un program să ruleze mai repede. Și programele trebuie să fie ușor de înțeles nu doar de programatorul care a scris-o, ci și de alți programatori care mențin codul. Aceste două Aforisme ne reamintesc că, dacă codul” de înaltă performanță ” este atât de complicat încât este imposibil pentru programatori să înțeleagă și să depaneze, atunci este un cod rău. Dar, din păcate, doar pentru că este ușor să explici codul unui program altcuiva nu înseamnă că nu este un cod rău. Programarea este dificilă.

spațiile de nume sunt o idee grozavă-să facem mai multe dintre acestea!

spațiile de nume (și, de asemenea, domeniile globale și locale) sunt esențiale pentru prevenirea numelor dintr-un modul sau domeniu de aplicare să intre în conflict cu numele din altul. Dar, de asemenea, amintiți-vă că flat este mai bun decât imbricate: oricât de mari sunt, spațiile de nume ar trebui făcute doar pentru a preveni conflictele de denumire și nu pentru a adăuga o clasificare inutilă.

ca toate opiniile despre programare, cele pe care le-am scris aici pot fi argumentate sau pot fi pur și simplu irelevante pentru situația dvs. Argumentarea asupra modului în care ar trebui scris codul este rareori la fel de productivă pe cât credeți că este. (Cu excepția cazului în care scrieți o carte întreagă plină de opinii de programare.)