Lecții din Zenul lui Python

Ce este Zenul lui Python? 

Zenul lui Python este un set de nouăsprezece aforisme care servesc drept principii directoare pentru designul Python. De fapt, ar fi trebuit să fie douăzeci de aforisme; dar Guido van Rossum, creatorul Python, încă nu a adăugat ultimul aforism așa cum intenționa Tim Peters, autorul Zenului lui Python. Se spune că Guido a declarat că al douăzecilea aforism lipsă este „o glumă internă bizară de-a lui Tim Peters”.

În ciuda celui de-al douăzecilea aforism lipsă, Zenul lui Python a fost standardizat ca PEP 20 în 2004 datorită influenței sale puternice asupra modului de lucru al programatorilor Python. Urmarea Zenului lui Python nu este obligatorie, dar este recomandat să îl cunoști și să îl ai în minte. Dacă uiți vreodată lecțiile, îți poți reîmprospăta ușor memoria rulând import this din interpretorul Python. 

>>> import this
The Zen of Python, by Tim Peters

Beautiful 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!

În acest articol, vom aprofunda fiecare lecție. 

#1 Frumosul e mai bun decât urâtul 

Dacă ești programator, nu există îndoială că ești foarte priceput. Capacitatea de a rezolva probleme cu cod nu e o sarcină ușoară, dar, ca Pythonist, se așteaptă mai mult de la tine. Codul frumos e mai bun decât codul urât. Ascensiunea rapidă a lui Python se datorează parțial accesibilității sale: este simplu, ușor de citit și elegant. Ca dezvoltator Python, ai responsabilitatea de a menține standardul „pythonic” scriind cod frumos. 

Ce înseamnă cod frumos? Ei bine, e subiectiv – frumusețea e în ochii privitorului și toate cele. O regulă simplă care să te țină pe drumul cel bun este să scrii cod curat, lizibil, care poate fi înțeles ușor de alți dezvoltatori. De exemplu: 

"""
Initial code was created by Vishal Sharma
See:  https://towardsdatascience.com/the-zen-of-python-a-guide-to-pythons-design-principles-93f3f76d088a
"""
def collatz(num):
    if num % 2 == 0:
        return num // 2
    else:
        return 3 * num + 1

number = input("Enter a number: ")

while number != 1:
    number = collatz(int(number))
    print(number)

"""
Enter a number: 5
16
8
4
2
1
"""

Codul de mai sus funcționează perfect, dar nu e neapărat frumos. Avem o condiție else inutilă în funcția noastră collatz, care poate fi eliminată astfel: 

def collatz(num):
  if num % 2 == 0:
      return num // 2
 
  return 3 * num + 1

Așadar, când ai de ales între două bucăți de cod care funcționează, optează pentru cea mai simplă, mai lizibilă și mai ușor de înțeles. 

#2 Explicitul e mai bun decât implicitul

A explica un aforism ca fiind „de la sine înțeles” e o mare greșeală – totuși, vei vedea oameni făcând asta. Esența din „explicitul e mai bun decât implicitul” este că un cod mai explicit e de preferat unuia care sugerează lucrurile pe ocolite. Fă tot ce poți pentru ca funcționalitatea codului tău să nu fie ascunsă în spatele unui limbaj obscur. Cineva fără cunoștințe anterioare despre programul tău ar trebui totuși să poată înțelege ce se întâmplă în codul tău. 

#3 Simplul e mai bun decât complexul

Probabil ai râde dacă prietenul tău ar scoate un aparat de spălat cu presiune ca să spele vasele după cină. Nu doar că e o soluție foarte năstrușnică, dar există și șanse mari să se strice farfuriile. În același fel, aplicarea unei soluții foarte complexe la o problemă simplă de programare e extrem de nepractică. Nu e nevoie să-ți complici excesiv soluția, chiar dacă crezi că asta te face să pari mai deștept. Poți provoca mai mult rău decât bine, iar asta nu e apreciat în Python. 

Uită-te la această funcție folosită pentru a inversa un șir: 

def reverse_string(string):
    if len(string) == 1:
        return string
    else:
        return reverse_string(string[1:]) + string[0]


string = "kurtis"

print(reverse_string(string))

"""
sitruk
"""

Codul de mai sus rezolvă cu siguranță problema, dar e inutil de complex. Dacă stăpânești bine Python, știi că un șir poate fi inversat prin indexare. 

string = "kurtis"

# annonymous function solution
reverse_string = lambda x: x[::-1]

# function solution
def reverse(string):
    return string[::-1]

print(reverse_string(string))
print(reverse(string))

"""
sitruk
sitruk
"""

#4 Complexul e mai bun decât complicatul 

Acum, să speli vasele cu un aparat de spălat cu presiune e nepractic: te-ai descurca mai bine cu o soluție simplă, cum ar fi apa de la robinet. Dar dacă problema ar fi să cureți un Range Rover 4x4? Aforismul anterior și acesta ne amintesc că atât tehnicile simple, cât și cele complexe pot fi aplicate pentru a rezolva o problemă. Curățarea unui Range Rover 4x4 nu e o problemă simplă, iar încercarea de a aplica aceleași tehnici ca la vase ar putea funcționa, dar e mai complicată decât folosirea unui jetwash. Așadar, preferă simplitatea în locul complexității, dar în situațiile în care simplitatea e nepractică, e mai bine să optezi pentru complexitate – cunoaște limitele simplității. 

#5 Platul e mai bun decât imbricatul 

Programatorilor le place să organizeze lucrurile în categorii, subcategorii și sub-subcategorii pentru a separa funcționalități. Deși poate părea ordonat, organizarea codului în acest mod poate duce la mai multă confuzie decât ordine. 

Nu e nimic rău în a pune tot codul tău într-un modul de nivel superior: ceea ce înseamnă că nu va trebui să faci ceva de genul from spam.foo.bar.john.doe import chicken pentru a accesa o funcționalitate anume. Cu cât adaugi mai multe subcategorii, cu atât codul devine mai complicat. Fă tot posibilul să rămâi la o structură plată atunci când e posibil.

#6 Aerisit e mai bun decât înghesuit

Programatorii sunt considerați printre cei mai inteligenți oameni, așa că nu e nevoie să-ți etalezi inteligența cu artificii exagerate. Cel mai des vei auzi „cum să faci [o sarcină complicată] în 1 linie de cod”. Uneori, one-liner-ele sunt justificate, dar evită situațiile în care compromiți lizibilitatea doar ca să înghesui toată funcționalitatea într-o singură linie. 

Iată, de exemplu, această bucată de cod: 

"""
Code source Al Sweigart
See: https://inventwithpython.com/blog/author/al-sweigart.html0
"""
print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 << i for i in range(8))))
"""
1 bytes = 8 bits which has 255 possible values.
2 bytes = 16 bits which has 65535 possible values.
4 bytes = 32 bits which has 4294967295 possible values.
8 bytes = 64 bits which has 18446744073709551615 possible values.
16 bytes = 128 bits which has 340282366920938463463374607431768211455 possible values.
32 bytes = 256 bits which has 115792089237316195423570985008687907853269984665640564039457584007913129639935 possible values.
64 bytes = 512 bits which has 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084095 possible values.
128 bytes = 1024 bits which has 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137215 possible values.
"""

Codul funcționează, dar e un coșmar de înțeles: e înghesuit și greu de citit. 

Hai să vedem cum ar arăta același cod dacă l-am scrie aerisit: 

# Sparse example
bytes_and_bits = {j: j*8 for j in (1 << i for i in range(8))}

for bytes, bits in bytes_and_bits.items():
    print(f"{bytes} bytes = {bits} which has {256**bytes-1} possible values")

"""
1 bytes = 8 which has 255 possible values
2 bytes = 16 which has 65535 possible values
4 bytes = 32 which has 4294967295 possible values
8 bytes = 64 which has 18446744073709551615 possible values
16 bytes = 128 which has 340282366920938463463374607431768211455 possible values
32 bytes = 256 which has 115792089237316195423570985008687907853269984665640564039457584007913129639935 possible values
64 bytes = 512 which has 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084095 possible values
128 bytes = 1024 which has 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137215 possible values
"""

Codul de mai sus e mult mai ușor de citit și face exact același lucru ca one-liner-ul.

#7 Lizibilitatea contează

Dacă nu ți-ai dat seama deja, în Python lizibilitatea contează. Sarcina ta este să scrii codul o singură dată. Totuși, sunt șanse mari să fie citit de mai multe ori. Ținând cont de asta, să renunți la vocale în numele variabilelor și funcțiilor nu e o idee bună: într-o situație în care poți numi o funcție create_lst sau create_list, alege-o pe a doua. 

#8 Cazurile speciale nu sunt suficient de speciale ca să încalce regulile

Python [și programarea în general] e plin de bune practici de urmat. E mai bine să urmezi practicile consacrate decât să o faci în felul tău, deoarece asta duce adesea la cod inconsistent și greu de citit. 

#9 Deși practicitatea învinge puritatea

Lecția nouă e o extensie a lecției opt. Da, e mai bine să urmezi bunele practici, dar să te forțezi cu orice preț să respecți regulile poate duce și la cod greu de citit. Așadar, fiecare regulă poate avea o excepție. Dacă modul tău de a rezolva o problemă e mai practic, mai lizibil și mai ușor de înțeles, atunci e mai bine să te abați de la practicile consacrate. 

#10 Erorile nu ar trebui niciodată trecute sub tăcere 

O eroare silențioasă e atunci când un program returnează un cod de eroare sau None în loc să ridice o excepție. E mai bine ca un program să se oprească decât ca eroarea să fie redusă la tăcere și execuția să continue. Pe termen lung, mascarea erorilor poate duce la bug-uri mult mai greu de eliminat. 

#11 Decât dacă sunt reduse la tăcere în mod explicit

Lecția unsprezece e o extensie a lecției zece. Există situații în care ai putea dori să ignori erorile produse de programul tău. În astfel de cazuri, cea mai bună practică este să reduci la tăcere eroarea în mod explicit în codul tău. 

#12 În fața ambiguității, refuză tentația de a ghici

Calculatoarele fac doar ceea ce le spunem: dacă programul tău nu se comportă cum ai vrea, e pentru că face ceea ce i-ai spus. Încercarea de a remedia comportamentul încercând orbește mai multe soluții până când una funcționează e o strategie slabă – s-ar putea să maschezi problema în loc să o rezolvi. Rezistă tentației. În schimb, gândește logic problema și aplică un raționament critic pentru a veni cu o soluție adecvată. 

#13 Ar trebui să existe o singură – și, de preferat, doar una – cale evidentă de a o face 

Deviza limbajului Perl este: „Există mai mult de o cale de a o face!” Prea multe opțiuni duc adesea la supraîncărcare decizională. Un scenariu similar apare când există mai multe moduri de a scrie cod care ating același scop. Ai mai multă flexibilitate în felul în care scrii codul, dar acum trebuie să înveți toate modurile posibile în care ar fi putut fi scris pentru a-l citi: munca suplimentară de a învăța toate scenariile e inutilă. 

#14 Deși acea cale s-ar putea să nu fie evidentă la început, decât dacă ești olandez

Acest aforism arată simțul umorului lui Tim Peters: Guido van Rossum, creatorul limbajului Python și Benevolent Dictator For Life (BDFL) pentru Python, este olandez. Este o glumă care ne amintește că a înțelege și a reține regulile limbajului Python e dificil pentru toată lumea, în afară de creatorul său. 

#15 Acum e mai bine decât niciodată

Acest aforism ne spune că un cod blocat într-o buclă infinită sau care atârnă e mai rău decât codul care nu o face. 

#16 Deși niciodată e adesea mai bine decât chiar acum

Continuând de la lecția a șaisprezecea: e mai bine să aștepți ca programul tău să-și termine execuția decât să-l oprești prematur și să obții rezultate incorecte. 

#17 Dacă implementarea e greu de explicat, e o idee proastă

Nu e suficient să îți înțelegi propriile implementări – „știu ce încerc să spun” nu e de ajuns. Programarea e o activitate de echipă, iar dacă nu poți explica implementarea colegilor tăi, e foarte probabil că ai făcut soluția prea complicată. 

#18 Dacă implementarea e ușor de explicat, s-ar putea să fie o idee bună

Totuși, faptul că un cod e ușor de explicat nu înseamnă neapărat că nu e cod prost – înseamnă doar că e ușor de explicat. E posibil să ai în continuare cod slab, dar faptul că e ușor de explicat înseamnă că ești pe drumul cel bun. 

#19 Spațiile de nume sunt o idee grozavă – hai să folosim mai multe!

Un spațiu de nume este o abstractizare folosită în Python pentru a organiza numele atribuite obiectelor dintr-un program. Având un anumit spațiu de nume și un anumit domeniu, Python poate determina la ce obiect te referi când apelezi un nume simbolic. Tot ce spune acest aforism este că modul în care Python organizează „sub capotă” numele simbolice e foarte tare. 

Concluzie 

În acest articol, ți-am prezentat interpretarea noastră a Zenului lui Python, ghiduri create pentru a-i motiva pe programatorii Python să scrie cod curat și lizibil. În timp ce unii privesc Zenul lui Python ca pe planul suprem pentru scrierea fără cusur a codului, alții îl iau mai puțin în serios.  Îți sugerăm să încerci să aplici principiile la propriul tău cod ca să vezi din prima mână cum îți pot îmbunătăți munca.  Dacă vrei să afli mai multe despre scrierea de cod optimizat, aruncă o privire la cursul DataCamp Writing Efficient Python Code.