Avec d'innombrables bonnes pratiques Python circulant en ligne, les opinions sur chacune peuvent varier en fonction de la personne à qui vous demandez. Internet a démocratisé l’expertise, permettant à chacun – moi y compris – de partager son point de vue. Cependant, dans cet article, nous nous concentrerons sur 10 meilleures pratiques intemporelles de Python qui ont fait l’objet d’un large consensus et sont largement considérées comme fondamentales.

Aide-mémoire Pandas

Aide-mémoire des commandes Git

Top 50 des questions d'entretien SQL

Astuce 1 : les fonctions doivent spécifier le paramètre et le type de retour
Lors de la définition d’une fonction, vous souhaitez toujours spécifier quels sont les types des arguments ainsi que le type de données renvoyé par le résultat de la fonction. Cela vous aiderait, vous et les développeurs de votre équipe, à savoir à quoi vous attendre sans toujours avoir à utiliser des instructions d'impression pour obtenir une compréhension visuelle.

Astuce 2 : les fonctions doivent être au même niveau d'abstraction
Lorsque nous parlons de fonctions se trouvant au même niveau d’abstraction, nous faisons référence à l’idée qu’une fonction doit effectuer une tâche unique et bien définie. Cette tâche doit se situer à un niveau d’abstraction cohérent tout au long de la fonction. En d’autres termes, la fonction doit se concentrer sur un niveau de détail ou de complexité spécifique, et toutes les opérations des fonctions doivent s’opérer à ce même niveau.

Astuce 3 : les fonctions doivent être petites
Une fonction est censée être réutilisable. Et plus la fonction est grande, moins elle a de chances d'être réutilisable. Cela correspond également à la raison pour laquelle une fonction ne doit faire qu’une seule chose. S’il ne fait qu’une seule chose, il y a de fortes chances que ce soit petit.

Astuce 4 : Principes ouverts et fermés
Le principe ouvert-fermé (OCP) stipule qu'une classe, une méthode ou une fonction doit être ouverte pour extension mais pas pour modification. Cela signifie que toute classe, méthode ou fonction définie peut être facilement réutilisée ou étendue pour plusieurs instances sans modifier son code.
Cela ne respecte pas l'OCP car chaque fois qu'il y a un nouveau pays, nous aurions besoin d'écrire une nouvelle instruction if pour compléter cela. Cela peut sembler simple maintenant, mais imaginez que nous ayons 100 pays ou plus à prendre en compte. À quoi cela ressemblerait-il ?

Astuce 5 : évitez les commentaires à tout prix
Les commentaires ont tendance à être faussement vrais. Ils détournent l’esprit du lecteur de ce que fait réellement le code vers ce que quelqu’un d’autre dit qu’il fait.

Cela peut devenir très problématique à mesure que le temps passe et que le code reçoit des mises à jour ou des modifications. À un moment donné, le commentaire devient un mensonge et chacun doit désormais observer la vérité à travers le prisme du mensonge.

Les commentaires doivent être évités à tout prix. Un commentaire oblige le lecteur à hériter de votre pensée qui, au mieux, appartient au passé. Lorsqu'une fonction ou une classe change, il est fort probable que ses commentaires ne changent pas avec elle. Très probablement, ils empêchent le lecteur de penser vers l’avenir.

Un commentaire signifie que l'auteur était mentalement incapable de fournir un nom de classe, de fonction ou de variable bien descriptif. Cela expose l'attitude terne du programmeur et oblige l'équipe à hériter d'une telle attitude.

Astuce 6 : évitez les nombres magiques
Un nombre magique est une valeur codée en dur qui peut changer ultérieurement, mais qui peut donc être difficile à mettre à jour.

Par exemple, disons que vous disposez d'une page qui affiche les 50 dernières commandes dans une page de présentation « Vos commandes ». 50 est le nombre magique ici car il n'est pas défini par une norme ou une convention, c'est un nombre que vous avez inventé pour les raisons décrites dans les spécifications.

Maintenant, ce que vous faites, c'est que vous avez les 50 à différents endroits : votre script SQL (SELECT TOP 50 * FROM commandes), votre site Web (vos 50 dernières commandes), votre identifiant de commande (pour (i = 0 ; i

Astuce 7 : évitez la nidification profonde
Limitez les niveaux d'imbrication dans les boucles, les conditions ou les fonctions pour améliorer la lisibilité.

Astuce 8 : évitez les chemins de codage en dur
Évitez de coder en dur les chemins de fichiers ou les URL ; utilisez plutôt des fichiers de configuration ou des variables d'environnement.

Astuce 9 : Les classes doivent être petites
Ouais! Les classes doivent être aussi petites que possible. Tout comme les fonctions.

La seule différence est que dans les fonctions, la taille est déterminée par le nombre de lignes dans cette fonction tandis que dans les classes, elle est déterminée par le nombre de responsabilités dans cette classe.

Habituellement, un nom de classe représente le type de responsabilités qu'elle peut assumer, mais lorsque le nom est ambigu ou trop général, nous lui donnons probablement trop de responsabilités.

Cela nous ramène au SRP (principe de responsabilité unique) qui stipule qu'une classe ne devrait avoir qu'une seule raison – une seule responsabilité – pour changer.

Astuce 10 : Évitez les expressions ternaires complexes
Évitez d'utiliser des expressions ternaires trop complexes ; privilégiez la lisibilité à la brièveté pour rendre le code plus compréhensible.