Sommaire
Dans le domaine du développement de logiciels, les développeurs travaillent généralement dans un environnement collaboratif en évolution rapide. Pour cette raison, il est fortement recommandé qu'ils suivent des directives et des pratiques de codage communes qui garantiront efficacité, clarté, détection facile des bogues et intégration. Après tout, un code correctement formaté et documenté a plus de chances d'être partagé et utilisé par l'ensemble de la communauté des développeurs
Nous proposons ici un ensemble d'outils de développement Python qui peuvent vous aider à atteindre un tel objectif, testés avec les versions de Python 3.8 :
- noir
- Flocon 8
- Je sorte
- Mypy
- Style pydoc
- Darglint
noir
noir est un outil de mise en forme rapide qui peut être utilisé très facilement en ligne de commande.
Le reformatage de votre code en noir vous permet de produire un code propre et lisible, ce qui facilite la détection des erreurs.
Dans cet exemple :
Course à pied :
Retours :
Et il transforme sample.py :
Configuration recommandée
Remarque: Skip-magic-trailing-comma : pour éviter de faire exploser une collection en un seul élément par ligne
Flocon 8
Flocon 8 est un outil qui enveloppe style pycode, pyflakes, et mccabe
- Style Pycode: détecte toute erreur de formatage dans le code lié à la conformité PEP8. Vous trouverez ci-dessous une liste non exhaustive des erreurs :
E pour les codes d'erreur et W pour les avertissements
- E1 : pour les erreurs d'indentation.
- E2 : pour les erreurs d'espacement.
- E7 : pour les erreurs de déclaration
- W6 : pour les avertissements de dépréciation
- Pyflakes: détecte toute incohérence dans le code. Vous trouverez ci-dessous une liste non exhaustive des erreurs :
F pour les codes d'erreur
- F4 : pour les erreurs d'importation
- F5 : pour les erreurs de format
- F6 : pour les assignations incompatibles/les erreurs de comparaison
- F7 : pour les erreurs de syntaxe
- F8 : pour les erreurs liées aux variables
- McCabe: détecte les erreurs de complexité.
Code d'erreur : C (erreur renvoyée toujours C901 pour violation de complexité)
Dans ce fichier sample.py :
Course à pied :
Vous donne les erreurs suivantes :
Configuration recommandée
Nous ignorons ces deux erreurs :
- Espace blanc E203 : qui est lié à l'interaction avec les outils noirs
- Ligne E501 : qui permet d'autoriser une ligne plus longue que la recommandation PEP8 de 79 caractères
Nous avons également un ensemble de plugins flake8 que vous pouvez installer :
- flake8-use-fstring : vérifiez % ou .format et suggérez d'utiliser des chaînes de f
- Flake-8-print : vérifier les relevés imprimés
- flake8-tidy-imports : écrire des importations plus ordonnées (interdit les importations depuis les modules parents et supérieurs, c'est-à-dire avec plus d'un.)
Je sorte
Je sorte est un outil qui fournit un utilitaire de ligne de commande qui trie vos importations (par ordre alphabétique et sépare les sections en importations standard, tierces, premières parties et enfin importations depuis le dossier local).
Dans cet exemple :
Course à pied :
Transforme le fichier sample.py :
Configuration recommandée
Nous devons définir le profil sur « noir » pour éviter de mauvaises interactions entre les deux outils.
Mypy
Mypy est un vérificateur de type statique. Vous devez saisir vos fonctions et variables pour l'utiliser. Vous pouvez configurer son niveau de rigueur si vous souhaitez toujours résoudre le type de manière dynamique dans certaines parties de votre code, mais n'oubliez pas que le fait d'avoir un projet typé de manière statique améliore la productivité et que la clarté ajoute des barrières de sécurité partout afin que vous puissiez détecter les erreurs avant même d'exécuter votre code.
Dans cet exemple :
Course à pied :
Retours :
Configuration recommandée
Nous avons choisi de n'exiger la saisie que pour le code de production et non pour les tests.
Pour une nouvelle base de code, vous devez ajouter options strictes mais pour le code existant, vous devez ajouter les options mypy de manière itérative.
Style pydoc
Style pydoc est un outil qui vérifie la conformité de la plupart des PERSONNE 257 concernant vos docstrings. Docstring est un outil essentiel pour documenter votre code. Nous avons choisi d'adopter le Convention de style Google.
Il implémente différents groupes d'erreurs :
- D1 : pour Docstrings manquantes
- D2 : pour les problèmes d'espaces blancs
- D3 : pour les problèmes de devis
- D4 : pour les problèmes de contenu Docstring
Configuration recommandée
Dans l'échantillon non documenté précédent :
Course à pied :
Retours :
Nous aurions dû :
Darglint
Darglint est un outil permettant de vérifier que la docstring correspond à l'implémentation de la fonction ou de la méthode tout au long de son cycle de vie. Cela évite d'avoir une documentation obsolète lorsque la signature a changé. Il est préférable de l'utiliser en combinaison avec un vérificateur de style docstring tel que pydocstyle.
Il implémente différents groupes d'erreurs :
- DAR0 : Syntaxe, mise en forme et style
- DAR1 : Section artistique
- DAR2 : Section des retours
- DAR3 : Section des rendements
- DAR4 : Section surélevé
- DAR5 : Section des variables
Dans l'exemple documenté précédent :
Course à pied :
Retours :
Nous aurions dû :
Intégration
Nous aimerions regrouper toutes ces configurations d'outils dans un seul fichier. Pour le stockage des configurations, nous vous recommandons d'utiliser .flake8 + pyproject.toml.
Ensuite, si nous voulons tous les exécuter en utilisant une seule commande, nous avons différentes options :
- Script SH pour Makefile
Nous devons définir une liste de dépendances de développement comme dans requirements-dev.txt.
Nous créons un fichier lint.sh (darglint est automatiquement lancé par flake8 lorsqu'il est installé dans le même environnement, donc pas besoin de le spécifier)
Et nous pouvons l'exécuter :
Si vous souhaitez utiliser un Makefile :
Exécutez ensuite :
- Pré-commit [Préféré]
Pré-valider est une autre alternative au regroupement de tous les outils et à leur exécution dans un environnement fermé dédié, de sorte que vous n'en ayez même pas besoin dans un environnement de développement.
De plus, il peut interagir avec le git hook concernant les fichiers modifiés lors de la validation, du push, etc. avant la soumission au stockage de code distant et éviter d'encombrer le CI pour des problèmes de lint et de style.
Configuration recommandée
.pre-commit-config.yaml
Conclusion
Une fois que vous aurez convergé vers une configuration et choisi une méthode d'intégration, votre flux de travail sera stable et productif. De plus, ils n'évolueront probablement pas beaucoup à l'avenir, il est donc évident de maintenir une base de code avec de tels outils.
De plus, lorsqu'il est utilisé dès le début d'un projet, le coût est proche de zéro, mais lorsqu'il est appliqué à une base de code existante, la résolution de toutes les erreurs peut prendre un certain temps. Plus vous commencez tôt, mieux c'est !
Image sélectionnée par Kuznetcov_Konstantin
À propos



.webp)

