Leçons du Zen of Python

Qu'est-ce que le Zen of Python ?

Le Zen of Python est un ensemble de dix-neuf aphorismes qui servent de principes directeurs pour la conception de Python. Il devait en fait y en avoir vingt ; mais Guido van Rossum, le créateur de Python, n'a toujours pas ajouté l'ultime aphorisme, comme l'avait envisagé Tim Peters, l'auteur du Zen of Python. Guido aurait déclaré que le vingtième aphorisme manquant était « une blague interne un peu décalée de Tim Peters ».

Malgré ce vingtième aphorisme absent, le Zen of Python a été normalisé sous le nom de PEP 20 en 2004, en raison de sa forte influence sur la façon de développer des programmeurs Python. Suivre le Zen of Python n'est pas obligatoire, mais le connaître et le garder à l'esprit est recommandé. Si jamais vous oubliez ces leçons, vous pouvez vous rafraîchir la mémoire en exécutant import this depuis l'interpréteur 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!

Dans cet article, nous allons passer en revue chaque leçon plus en détail. 

#1 Le beau vaut mieux que le laid 

Si vous êtes développeur, nul doute que vous avez un haut niveau de compétence. Résoudre des problèmes avec du code n'est pas une mince affaire, mais en tant que Pythonista, on attend davantage de vous. Un code élégant vaut mieux qu'un code brouillon. La montée en puissance de Python tient en partie à son accessibilité : c'est un langage simple, lisible et élégant. En tant que développeur Python, vous avez la responsabilité de maintenir cet esprit « pythonic » en écrivant un beau code. 

Qu'est-ce qu'un beau code ? C'est subjectif : la beauté est dans l'œil de celui qui regarde. Une règle simple pour rester sur la bonne voie : écrivez un code propre et lisible, facile à comprendre par d'autres développeurs. Par exemple : 

"""
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
"""

Ce code fonctionne très bien, mais il n'est pas forcément élégant. Le else de la fonction collatz est inutile et peut être supprimé comme suit : 

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

Ainsi, si vous hésitez entre deux versions qui marchent, choisissez celle qui est la plus simple, la plus lisible et la plus facile à comprendre. 

#2 L'explicite vaut mieux que l'implicite

Dire d'un aphorisme qu'il est « évident » est une grosse erreur ; vous verrez pourtant des gens le faire. L'idée est que du code explicite, même un peu verbeux, est préférable à du code indirect. Faites en sorte que la fonctionnalité de votre code ne soit pas cachée derrière des constructions obscures. Quelqu'un qui ne connaît pas votre programme devrait pouvoir comprendre ce qu'il s'y passe. 

#3 Le simple vaut mieux que le complexe

Vous ririez si un ami sortait un nettoyeur haute pression pour faire la vaisselle après le dîner. Non seulement la solution est absurde, mais elle risque en plus d'abîmer l'assiette. De même, appliquer une solution très complexe à un problème simple de programmation est peu pratique. Inutile de surcompliquer, même si vous pensez que cela vous fait paraître brillant. Vous risquez plus de dégrader les choses : ce n'est pas l'esprit de Python. 

Regardez cette fonction qui inverse une chaîne : 

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
"""

Ce code résout le problème, mais il est inutilement complexe. Si vous maîtrisez Python, vous savez qu'on peut inverser une chaîne avec l'indexation. 

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 Le complexe vaut mieux que le compliqué 

Laver des assiettes au nettoyeur haute pression est peu pratique : un simple robinet suffit. Mais si l'on doit nettoyer un 4x4 Range Rover ? Ces deux aphorismes rappellent qu'on peut résoudre un même problème avec des techniques simples ou complexes. Nettoyer un 4x4 n'est pas un problème simple, et utiliser les m&ecil;mes méthodes que pour la vaisselle peut s'avérer plus compliqué que d'utiliser un nettoyeur haute pression. Privilégiez la simplicité, mais quand elle atteint ses limites, sachez recourir à la complexité pertinente. 

#5 Le plat vaut mieux que l'emboîté 

Les développeurs adorent tout classer en catégories, sous-catégories et sous-sous-catégories pour séparer les fonctionnalités. En apparence ordonné, ce type d'organisation peut générer plus de confusion que de clarté. 

Rien de mal à réunir l'ensemble de votre code dans un module de premier niveau : vous n'aurez pas à faire un from spam.foo.bar.john.doe import chicken pour accéder à une fonctionnalité précise. Plus vous multipliez les niveaux, plus votre code se complique. Privilégiez une structure plate quand c'est possible.

#6 L'aéré vaut mieux que le compact

Les programmeurs sont considérés comme parmi les esprits les plus affûtés ; inutile de souligner votre brio par des astuces tarabiscotées. La rengaine « faire [une tâche complexe] en une seule ligne » revient souvent. Parfois, les one-liners se justifient, mais évitez de sacrifier la lisibilité juste pour tout faire tenir sur une ligne. 

Prenez ce morceau de code en exemple : 

"""
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.
"""

Ce code fonctionne, mais c'est un cauchemar à lire : tassé et difficile à déchiffrer. 

Voyons à quoi ressemble le même code écrit de façon aérée : 

# 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
"""

Ce code est bien plus lisible et réalise exactement la même chose que la version en une ligne.

#7 La lisibilité compte

Si vous ne l'aviez pas encore compris, en Python, la lisibilité compte. Votre travail est d'écrire le code une fois. Mais il sera probablement lu maintes fois. Dans ce contexte, évitez de supprimer des voyelles dans les noms de variables ou de fonctions : si vous hésitez entre create_lst et create_list, préférez la seconde. 

#8 Les cas particuliers ne justifient pas d'enfreindre les règles

Python, comme la programmation en général, s'appuie sur des bonnes pratiques à suivre. Mieux vaut s'y tenir que faire à sa façon : on finit souvent avec un code incohérent et peu lisible. 

#9 Mais le pragmatisme l'emporte sur la pureté

La neuvième leçon prolonge la huitième. Oui, mieux vaut suivre les bonnes pratiques, mais s'y accrocher à tout prix peut aussi mener à un code illisible. Chaque règle a donc ses exceptions. Si votre solution est plus pratique, plus lisible et plus facile à comprendre, il vaut mieux s'écarter des conventions établies. 

#10 Les erreurs ne devraient jamais passer sous silence 

Une erreur silencieuse survient quand un programme renvoie un code d'erreur ou None au lieu de lever une exception. Il vaut mieux qu'un programme plante plutôt que de masquer l'erreur et continuer. À long terme, faire taire les erreurs engendre des bogues bien plus difficiles à traquer. 

#11 Sauf si elles sont réduites au silence explicitement

La onzième leçon prolonge la dixième. Parfois, vous pouvez vouloir ignorer certaines erreurs. Dans ces cas, la bonne pratique est de les neutraliser explicitement dans votre code. 

#12 Face à l'ambiguïté, refusez la tentation de deviner

Les ordinateurs ne font que ce qu'on leur dit de faire : si votre code ne se comporte pas comme prévu, c'est qu'il fait exactement ce que vous lui avez indiqué. Essayer de corriger à l'aveugle en testant des solutions au hasard jusqu'à ce que ça marche est une mauvaise stratégie : vous risquez de masquer le problème sans le résoudre. Résistez à cette tentation. Raisonner sur la logique du problème et appliquez votre pensée critique pour trouver la bonne solution. 

#13 Il devrait y avoir une façon — et de préférence une seule — évidente de le faire 

La devise du langage Perl est : « There's more than one way to do it! » Trop d'options mènent au paradoxe du choix. En programmation, quand plusieurs façons existent pour atteindre le même résultat, vous gagnez en flexibilité, mais vous devez aussi connaître toutes ces variantes pour lire le code. Cet effort supplémentaire est superflu.

#14 Même si cette façon n'est pas évidente au début, à moins d'être néerlandais

Cet aphorisme illustre l'humour de Tim Peters : Guido van Rossum, créateur de Python et Benevolent Dictator For Life (BDFL), est néerlandais. C'est un clin d'œil pour rappeler que comprendre et retenir toutes les règles de Python est difficile pour tout le monde... sauf pour son créateur.

#15 Maintenant vaut mieux que jamais

Cet aphorisme nous dit qu'un code bloqué dans une boucle infinie ou qui se fige est pire qu'un code qui ne tourne pas. 

#16 Même si jamais est souvent préférable à « là, tout de suite »

Dans le prolongement : mieux vaut attendre la fin d'exécution de votre programme que de l'interrompre prématurément et obtenir des résultats erronés. 

#17 Si l'implémentation est difficile à expliquer, c'est une mauvaise idée

Il ne suffit pas de se comprendre soi-même : « je vois où je veux en venir » ne suffit pas. La programmation est un sport d'équipe ; si vous ne parvenez pas à expliquer votre implémentation à vos collègues, il est probable que votre solution soit trop compliquée. 

#18 Si l'implémentation est facile à expliquer, c'est peut-être une bonne idée

Cela dit, un code facile à expliquer n'est pas forcément un bon code ; cela signifie seulement qu'il est clair. Vous n'êtes pas loin de la bonne voie.

#19 Les espaces de noms sont une sacrée bonne idée — multiplions-les !

Un espace de noms est une abstraction utilisée en Python pour organiser les noms associés aux objets d'un programme. Avec un espace de noms et une portée donnés, Python sait à quel objet vous faites référence lorsque vous appelez un nom symbolique. En bref, la façon dont Python organise ces noms sous le capot est vraiment bien conçue.

Conclusion 

Nous avons partagé notre interprétation du Zen of Python, un ensemble de repères pensés pour encourager l'écriture d'un code propre et lisible. Certains y voient la méthode ultime pour coder sans accroc, d'autres le prennent avec plus de légèreté. Testez ces principes dans votre propre code et voyez, par vous-même, comment ils améliorent vos résultats.  Pour aller plus loin sur l'optimisation, consultez le cours de DataCamp Writing Efficient Python Code.