11/11/2024
PEP et les bonnes pratiques de codages.
Être un bon programmeur ne s'agit pas que de savoir écrire des lignes de codes mais il faut surtout savoir respecter les normes, conventions et les bonnes pratiques décrites dans les différents PEPs
Dans cette formation, nous parlerons de 15 aphorismes indispensables aux bonnes pratiques du codage, que vous devez connaître et appliquer. Ces 15 aphorismes proviennent de PEP 20 - The Zen of Python(qui est une collection de 19 aphorismes qui reflètent la philosophie derrière Python, ses principes directives et sa conception).
C'est quoi un PEP? PEP(Python Enhancement Proposals) est un document en ligne, qui décrit les normes et fournit des informations sur de nombreux changements et processus du langage Python.
Ces aphorismes sont:
1. Beautiful is better than ugly:
Même si l'ordinateur ne se souci pas de la beauté ou de l'esthétique, les gens le fond et nous devons nous rappeler qu'un programme bien écrit est aussi plus agréable à lire.
Python a certaines règles que le programmeur sont invités à respecter:
a) une longueur de ligne maximale de 79 caractères,
b) des convention de nommames des variables, des fonctions, de classes, des modules, ....
c) le placement des des instructions sur des lignes séparées ...
2. Explicit is better than implicite:
Le code que vous écrivez doit être explicite et lisible.
Chaque fois que vous souhaitez utiliser une fonctionnalité implicite du langage, demandez-vous si vous en avez vraiment besoin. Il existe peut être une meilleure façon d'implémenter la fonctionnalité, sinon pensez à laisser un commentaire dans le code pour explique ce qui se passe afin que les autres programmeurs le comprennent plus facilement.
Ajoutez plus de verbosités et donnez des noms de variables et fonctions explicites, donnez des explications aux importations et aux arguments de fonctions, ...
3. Simple is better than complex:
Une solution plus simple est généralement préférée à une solution complexe.
Envisagez de ne pas adopter une approche orienté objet lorsque cela n'est pas nécessaire. Utilisez moins de lignes de codes si cela est possible
4. Complex is better than Complicated:
Lorsque des solutions simples ne sont pas possibles, utilisez plutôt des solutions complexes.
Distinguez le complexe comme composé de nombreux éléments et le compliqué comme difficile à comprendre.
Lorsque votre code devient volumineux et trop difficile à comprendre, divisez le en parties bien séparées, afin qu'il soit plus facile à gérer et à manipuler.
5. Flat is better than nested(Plat vaut mieux qu'imbriqué):
Limitez si possible les imbrications des boucles ou les instructions if à trois niveau.
6. Sparse is better than dense:
N'écrivez pas trop de codes sur une seule ligne, n'insérez pas trop d'informations dans une petite quantité de codes, n'écrivez pas de lignes de code trop longues, utilisez les espaces de manière responsable, tout cela affecte la lisibilité et la compréhension de votre programme
7. Readability counts(la lisibilité compte):
Votre code n'est pas seulement lu par les ordinateurs, il est aussi (ou surtout) lu par les humains.
Le code est souvent plus lu qu'il n'est écrit(Guido Van Rossum).
Donnez des noms significatifs aux variables, fonctions, modules, et class, stylisez correctement les blocs de codes en utilisant des commentaires si nécessaire.
8. Special cases aren't special enough to break the rules(les cas spéciaux ne sont pas assez spéciaux pour enfreindre les règles):
La disciple, la cohérence et le respect des normes et des conventions sont tous des éléments importants dans l'élaboration d'un code professionnel et responsable. Il ne devrait y avoir aucune exception qui nous permette d'enfreindre les principes régissant les meilleurs pratiques de codages
9. Although, practicality beats purity (Bien que l'aspect pratique l'emporte sur la pureté):
Que se passe-t-il ici?
l'aphorisme précédent nous encourageait à ne pas enfreindre les règles, tandis que celui-ci dit qu'il pourrait y avoir des exceptions à cela.
Si vous devez écrire une longue linge de 85 caractères parce que la divisée en deux lignes distinctes affecte la lisibilité du code, faites le.
10. Errors should never pass silently unless explicitly silenced(Les erreurs ne doivent jamais passer en silence sauf si explicitement réduit en silence):
Analysez une situation potentiellement dangereuse ci-dessous:
number = input("Enter a number”)
multiply_number_by_two = number * 2
print(“Your number multiply by two is”, multiply_number_by_two)
Supposons que le programmeur ait oublié de convertir la valeur assignée à la variable number en int ou float. Le programme ne plantera pas, au contraire il fonctionnera sans aucun problème et produira un bon résultat bien que loin d’être prévu.
Si l’extrait ne constitue qu’une infime partie de l’ensemble du code, le programmeur peut avoir des difficultés à trouver la source de l’erreur vu que le programme n’a affiché aucun message d’erreur .
Apportons quelques modifications:
number = int("Enter a number”)
multiply_number_by_two = number * 2
print(“Your number multiply by two is”, multiply_number_by_two)
Que passera t’il si l’utilisateur saisit une valuer non int? Eh bien il déclenchera une exception ValueError.
Un programme qui plante est bien plus facile à débogguer q’un programme qui fait taire une erreur.
Le déclenchement d’une exception attire votre attention sur le problème et fournit des informations importantes sur ce qui se passe. Les erreurs qui passent silencieusement peuvent infecter le programme et modifier sont fonctionnement de sorte qu’il devienne imprévisible inattendu et indésirable.
11. In the face of ambiguity, refuse to he temptation to guess(Face à l’ambiguïté, refusez la tentation de deviner):
Les suppositions fonctionneront sûrement dans de nombreux cas, mais dans de nombreux autres cas, elles pourraient vous décevoir amèrement.
La première chose à retenir est de toujours tester votre code avant de le publier en production et de le deployer chez le client.
De la même manière, si vous pensez qu’il y a quelque chose qui ne va pas dans le code que vous lisez, il y a quelque chose de flou, ne devinez pas son fonctionnement.
Analysons l’exemple suivant:
fun(1, 2, 3)
fun(a=1, b=2, c=3)
Les deux invocations de fonctions peuvent être identiques, mais pas forcement. Il n’est pas possible de le savoir sans voir la definition de la fonction. Si la définition de la fonction ressemble à celle-ci-dessous, les résultats peuvent differer
def fun(x=0, y=0, z=0, a=1, b=2, c=3):
pass
Si vous travaillez sur un programme qui accepte les données de l’utilisateur, ne vous fiez pas à vos suppositions, par exemple si vous écrivez une application qui accepte les texte de l’utilisateur, spécifiez l’encodage que vous attendez d’eux et n’acceptez que cet encodage.
Cherchez toujours des contextes dans lesquelles votre programme pourrait planter et corriger les. Ne vous fiez pas à vos suppositions ou à votre conviction que l’utilisateur suivra strictement vos instructions.
12. There should be one-- and preferably only one --obvious way to do it(Il devrait y avoir une – et de préférence une seule – façon évidente de le faire.):
Il peut y avoir plusieurs façons d’atteindre le même objectif. Par exemple si souhaitez prendre le nom et prénom d’un utilisateur et les afficher à l’écran, vous pouvez le faire de l’une des manière suivantes:
first_name = input("Enter your first name“)
last_name = input("Enter “your last name”)
print(“Your name is: ”, first_name, last_name)
print(“Your name is” + “ ” + first_name + “ ” + last_name)
print(“Your name is {} {}”.format(first_name, last_name))
Lequel d’entre eux est le préféré? Cela dépend de ce que vous voulez réalise, de la manière dont vous souhaitez formater le texte généré.
Enfin l’aphorisme fonctionne comme une indication douce, d’un conseil important: dans la mesure du possible, il est bon de se rappeler que chaque fonction, chaque classe, chaque méthode, chaque entité doit avoir une seule responsabilité cohérente. Pourquoi? Parce qu’une telle approche vous aide à gagner en clarté et produit un code plus propre, rend sa maintenance plus facile, moins coûteuse et moins vulnérable aux bogues
13. Now is better than never(Maintenant est. mieux que jamais):
Vous ne devez pas remettre à demain ce que vous pouvez faire aujourd’hui.
Python vous permet de traduire rapidement vos idées en code fonctionnel. Chaque fois que vous ressentez l’effet eurêka, ou que vous avez votre moment d’inspiration, écrivez vos pensées et encodez-les
14. 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 (Si la mise en oeuvre est difficile à expliquer, c’est une mauvaise idée, si la mise en oeuvre est facile à expliquer, cela peut être une bonne idée):
Tout ce qui peut être expliqué avec des mots peut être traduit en code et éventuellement traduit en programme informatique.
Gardez les choses simples, plus c’est simple mieux c’est.
15. Namespace are one honking great idea - let’s do more of those(Les espaces de noms sont une excellente idée - faisons-en plus!)
Python fournit un bon mécanisme d’espace de noms bien organisés pour gérer la disponibilité des identifiants que vous souhaitez utiliser et éviter les conflits avec les noms déjà existants dans différentes portées.
Qu’est-ce qu’un espace de nom? D’une manière générale, c’est un mappage des noms aux objets “implémenté en Python sous forme d’un dictionnaire”
Qu’est-ce ça veut dire? En terme simple, cela signifie que chaque fois que vous définissez une variable, Python se souvient de deux choses: l’identifiant de la variable et la valeur que vous lui transmettez.
Comment ça se passe? Python les ajoute implicitement à un dictionnaire interne qui reside dans une portée particulière. Si vous souhaitez accéder à cette variable, Python cherche son nom dans le dictionnaire et renvoie sa valeur qui lui est transmise. Si la variable n’existe pas, une exception NameError est levée.
Fonctions, Classes, Modules, packages, … ce sont des espaces de noms.
Utilisez les espaces de noms pour rendre votre code plus clair et plus lisible. Par exemple faites ceci:
from instruments import guitars
guitars.fender(page)
guitars.fun(vrai)
Au lieu de cela:
from instruments.guitars import fender, fun
fender(page)
fun(vrai)
Pourquoi? Parce que le premier exemple montrera clairement que fender et fun proviennent du même module et le second exemple on n’a pas cette impression.
