Comment le Zen de Python peut vous aider à écrire un meilleur code

Vous voulez vous améliorer dans l'écriture de code Python ? Voici comment le Zen de Python peut vous aider à faire les premiers pas vers cela.

Python est super simple à apprendre. Mais écrire du code idiomatique et Pythonic facile à maintenir peut être difficile, en particulier pour les programmeurs débutants. PEP-20 a présenté "The Zen of Python", un poème de Tim Peters, qui souligne l'importance d'écrire du code Pythonic qui adhère aux meilleures pratiques.

Pour lire le Zen de Python, vous pouvez lancer un REPL Python et lancer :

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

Comme on le voit, la plupart des aphorismes du Zen de Python s'expliquent d'eux-mêmes. Certains aphorismes doivent être couplés au suivant lors de l'interprétation, tandis que d'autres contredisent un aphorisme antérieur. Néanmoins, le Zen de Python est une lecture amusante, engageante et pratique !

Interpréter le Zen de Python

Le Zen de Python a été proposé d'avoir 20 principes directeurs pour la programmation en Python. Cependant, il n'y a que 19 aphorismes à ce jour. Passons en revue.

Beautiful is better than ugly.

Cet aphorisme souligne l'importance d'écrire du code élégant et Pythonique.

L'extrait de code suivant a une odeur de code :

def square(num):
    squares = []
    for i in range(num):
        squares.append(i*i)
    return squares

La fonction: 

• Initialise une liste vide 
• A une boucle à l'intérieur de la fonction qui ajoute des éléments à la fin de la liste et 
• Renvoie enfin une liste 

Alors que ce is fonctionnellement correct - ce n'est pas Pythonic - et est difficile à maintenir.

Vous pouvez l'écrire beaucoup plus élégamment en utilisant des générateurs. Voici la fonction génératrice équivalente à la fonction ci-dessus :

def square(num):
    for i in range(num):
        yield i*i

Ou encore mieux, vous pouvez avoir l'expression de compréhension du générateur suivante :

num = ...
squares = (i*i for i in range(num))

Explicit is better than implicit.

Lorsque vous écrivez du code, ne laissez pas les autres développeurs et utilisateurs deviner le comportement implicite ou par défaut du code. Soyez explicite. Prenons l'exemple des importations de caractères génériques :

from some_module import * # wildcard import
from some_other_module import *

result = some_function() # where did this come from?

Évitez autant que possible d'utiliser des importations de caractères génériques. Parce qu'il n'est pas explicite et inefficace. Soyez précis lorsque vous importez des fonctions et des classes à partir d'autres modules :

from some_module import this_function # explicit import

result = this_function() # we now know.

Simple is better than complex.

Cet aphorisme stipule que nous devons garder le code simple et éviter toute complexité inutile. Par exemple : vous pouvez vouloir inverser une chaîne et vous implémentez la solution récursive suivante :

def reverse_string(my_string):
  if my_string == "":
    return my_string
  else:
    return reverse_string(my_string[1:]) + my_string[:1]

Bien que cela fonctionne, il s'agit probablement d'une solution trop sophistiquée à ce problème, étant donné qu'il existe des moyens plus simples et plus Pythoniques de le faire.

Voici l'approche de découpage de chaîne :

>>> rev_string = my_string[::-1]
>>> rev_string
'nohtyP'

Et voici l'approche utilisant des méthodes et des fonctions intégrées :

>>> rev_string = ''.join(reversed(my_string))
>>> rev_string
'nohtyP'

Complex is better than complicated.

Alors, que véhicule ce prochain aphorisme du Zen de Python ? 

L'inversion de chaîne en Python est une opération très simple. En pratique, cependant, nous pouvons avoir besoin d'une logique plus complexe. Voici un exemple assez simple :

Supposons que vous deviez vous connecter à une base de données :

• Vous devez d'abord analyser un fichier de configuration toml pour récupérer les informations de configuration de la base de données.
• Le connecteur de base de données doit être installé. 
• Vous pouvez ensuite définir une fonction pour vous connecter à la base de données, anticiper les erreurs de connexion, mettre en œuvre la gestion des erreurs, et bien plus encore.
• Enfin, après vous être connecté à la base de données, vous pouvez l'interroger.

Bien que cela soit encore assez simple, il nécessite une logique plus complexe par rapport à l'inversion de chaîne. Mais ça ne veut pas dire que ça doit être compliqué. Vous pouvez toujours utiliser efficacement les fonctionnalités du code des modules intégrés et organiser votre code afin que d'autres développeurs puissent le lire, le comprendre et y contribuer.

Flat is better than nested.

Une structure plate est plus facile à analyser et à comprendre qu'une structure imbriquée. Lorsque vous travaillez sur un projet, vous pourriez être tenté d'isoler les fonctionnalités en créant des modules distincts. Cependant, trop de granularité peut être excessif.

Cela dit, vous devrez peut-être souvent aller au-delà de la structure plate. Mais même si vous avez besoin d'imbrication, limitez-la au minimum.

Voici un exemple:

from db_info.config.actions.parse.parse_config import parse_toml # too difficult to parse!
...

from db_config.parse_config import parse_toml # much better!
...

Sparse is better than dense.

Si vous débutez dans votre parcours de développeur, vous pourriez être tenté de trop utiliser certaines des fonctionnalités du langage. Liste des compréhensions, par exemple, sont Pythonic, mais uniquement lorsque vous les utilisez là où ils sont nécessaires.

Regardez la compréhension suivante :

prices_dict = {'melons':40,'apples':70,'berries':55}
items = [(fruit,price) for fruit in prices_dict.keys() if fruit.startswith('m') for price in prices_dict.values() if price < 50]
print(items)
# Output: [('melons', 40)]

La compréhension de la liste est trop dense et difficile à analyser. Dans ce cas, utiliser une boucle for équivalente avec des conditions sera plus lisible. Signifiant le la compréhension est difficile à appréhender. ????

Readability counts.

Vous devez toujours écrire du code lisible. Voici quelques moyens simples d'améliorer la lisibilité du code :

• Utilisation de noms de variables descriptifs
• Ajout de docstrings pour les fonctions et les classes
• Code de commentaire si nécessaire
• Ajout d'indications de type pour les arguments et les types de retour des fonctions

Special cases aren’t special enough to break the rules.

Vous devez, dans la mesure du possible, respecter les règles du langage et les bonnes pratiques recommandées.

Mais est-ce toujours possible ? Non, et c'est pourquoi nous avons le prochain aphorisme.

Although practicality beats purity.

C'est la suite de l'aphorisme précédent. Bien qu'il soit recommandé de suivre les règles de la langue, dans certains cas, il est parfaitement acceptable de ne pas suivre certains principes.

Errors should never pass silently.

Dans Python, les erreurs d'exécution sont assez courantes. En tant que bonne pratique, vous devez toujours gérer les erreurs et ne pas les réduire au silence comme une solution rapide.

Vous pouvez anticiper et mettre en œuvre une gestion des erreurs appropriée, pour les différents types d'erreur :

try:  
    # doing this
except ErrorType1:
    # do something
except ErrorType2:
    # do something else
...

Vous devez éviter les exceptions nues et génériques. Les nouvelles versions de Python (depuis Python 3.11) prennent en charge le chaînage d'exceptions et les groupes d'exceptions pour effectuer gestion des exceptions plus sophistiquée.

Unless explicitly silenced.

Cela fait suite à l'aphorisme précédent. Si la conception exige ou permet que l'erreur soit réduite au silence, cela doit être fait explicitement.

Par exemple : lors de la connexion à la base de données, vous pouvez rencontrer OperationalError en raison d'informations de configuration invalides. Essayez de vous connecter en utilisant une configuration personnalisée. Au cas où il y aurait un OperationalError, utilisez la configuration par défaut et essayez de vous connecter à la base de données.

try:
   # connecting using custom config
except OperationalError:
   # connect using default config

In the face of ambiguity, refuse the temptation to guess.

Cet aphorisme dans le Zen de Python est explicite. En cas de doute, ne devinez pas. Mais exécutez le code et vérifiez la sortie. Ensuite selon que vous avez le comportement souhaité, améliorez la lisibilité ou modifiez la logique au besoin.

Prenons l'exemple simple suivant avec un tuple de booléens :

>>> True, True == (True, True)
(True, False)
>>> True, (True == (True, True))
(True, False)
>>> (True, True) == (True, True)
True

There should be one– and preferably only one –obvious way to do it.

Pour accomplir une certaine tâche, il devrait y avoir une et une seule façon pythonique recommandée de le faire. Cependant, pour tout problème, nous pouvons avoir plusieurs solutions.

Même dans l'exemple simple d'inversion de chaîne, nous avons examiné une solution récursive, le découpage de chaîne et le join() méthode.

C'est aussi une blague à l'intérieur étant donné l'utilisation incohérente des tirets. Nous utilisons généralement des tirets cadratin sans espaces de début et de fin. Ou nous l'utilisons avec les espaces de début et de fin.

Voici donc ce que nous pouvons en déduire. L'aphorisme qui insiste sur le fait qu'il devrait y avoir une - et une seule - manière Pythonique de faire les choses peut lui-même être écrit de plus de deux manières.

Although that way may not be obvious at first unless you’re Dutch.

Écrit sur une note légère, cela fait référence à Guido Van Rossum, le créateur de Python (qui est néerlandais). La manière (la plus) Pythonique d'accomplir une tâche particulière n'est naturelle que pour les créateurs de Python.

Donc, pour les développeurs, cela demande de l'expérience et apprendre de l'expérience– pour mieux exploiter les fonctionnalités de la langue.

Now is better than never.

Comme pour quelques autres aphorismes du Zen de Python, celui-ci peut également être interprété de différentes manières.

Une interprétation est qu'en tant que développeur, il est assez courant de tergiverser pour commencer à coder un projet. Plutôt que d'attendre pour planifier les moindres détails du projet, commencer maintenant est une meilleure idée.

Une autre interprétation possible est la suivante : un code qui s'exécute en un nombre fini d'étapes (et se termine) est souvent meilleur qu'un code bogué et bloqué dans une boucle infinie. 

Although never is often better than right now.

Cet aphorisme semble contredire le précédent. Bien qu'il soit préférable de ne pas tergiverser, nous devons quand même réfléchir au problème et concevoir le code en conséquence.

Coder un module - sans y réfléchir correctement - rempli d'odeurs de code et d'anti-modèles est une mauvaise idée. Parce qu'un tel code est difficile à refactoriser et à mettre en œuvre des mesures correctives.

If the implementation is hard to explain, it’s a bad idea.

Toute logique, aussi complexe soit-elle, peut toujours être mise en œuvre sous une forme simple à expliquer et facile à comprendre.

Si la mise en œuvre est difficile à expliquer, il y a probablement une complexité inutile. Le code peut être modifié ou refactorisé afin qu'il soit plus facile à suivre.

If the implementation is easy to explain, it may be a good idea.

Ceci est lié à l'aphorisme précédent et s'explique également de lui-même. Si la mise en œuvre peut être expliquée en termes simples, alors il est Probable une bonne idée.

Parce qu'un tel code dont l'implémentation peut être décrite - en termes simples - est très susceptible d'être lisible et facile à suivre - avec une complexité minimale.

Namespaces are one honking great idea — let’s do more of those!

En Python, les objets d'une portée spécifique sont accessibles en utilisant leurs noms dans leur espace de noms. Par exemple, vous pouvez créer une classe et l'utiliser comme modèle pour créer des instances de la classe. Maintenant, les variables d'instance seront toutes dans l'espace de noms de l'instance.

Cela nous permet d'utiliser des objets portant le même nom, sans conflits, car ils se trouvent dans des espaces de noms différents. Cependant, vous ne devez les utiliser que si nécessaire et vous assurer que la simplicité et la lisibilité du code ne sont pas compromises.

Conclusion

C'est tout pour ce tutoriel ! J'espère que ce guide vous a aidé à comprendre comment le Zen de Python met l'accent sur le style de code et les bonnes pratiques de codage en Python. Plus vous codez, mieux vous y parviendrez.

Si vous souhaitez apprendre à écrire du code concis et lisible, lisez cet article sur Python one-liners.