Maîtriser la qualité du code Python

Dans cet article, nous allons identifier du code Python de haute qualité et vous montrer comment améliorer la qualité de votre code.

Nous analyserons et comparerons les outils que vous pouvez utiliser pour faire passer votre code à un niveau supérieur.

Que vous utilisiez Python depuis un certain temps ou que vous en soyez à ses débuts, vous pouvez bénéficier des pratiques et des outils dont il est question ici.

Comment mesurer la qualité de son code ?

Bien sûr que tu veux un code de qualité, qui ne le voudrait pas ? Mais pour améliorer la qualité du code, nous devons définir ce que c'est.
Une recherche rapide sur Google donne de nombreux résultats définissant la qualité du code. Il s'avère que le terme peut signifier beaucoup de choses différentes pour les gens.

Une façon d'essayer de définir la qualité du code est d'examiner une extrémité du spectre : le code de haute qualité. Nous espérons que vous serez d'accord sur les identificateurs de code de haute qualité suivants :

  • Il fait ce qu'il est censé faire.
  • Il ne contient pas de défauts ou de problèmes.
  • Il est facile à lire, à maintenir et à étendre.

Ces trois identificateurs, bien que simplistes, semblent faire l'unanimité. Dans un effort pour développer davantage ces idées, examinons pourquoi chacune d'entre elles est importante dans le domaine du logiciel.

Pourquoi la qualité du code est-elle importante ?

Pour déterminer pourquoi un code de haute qualité est important, revoyons ces identificateurs. On verra ce qui se passera si le code ne les respecte pas.

Il ne fait pas ce qu'il est censé faire

Le respect des exigences est à la base de tout produit, logiciel ou autre. Nous faisons des logiciels pour faire quelque chose. Si à la fin, il ne le fait pas... eh bien, ce n'est certainement pas de la grande qualité. 

S'il ne répond pas aux exigences de base, il est même difficile d'appeler cela de la mauvaise qualité.Il contient des défauts et des problèmes

Si quelque chose que vous utilisez a des problèmes ou vous cause des problèmes, vous ne l'appelleriez probablement pas de grande qualité.

En fait, si c'est assez mauvais, vous pouvez même arrêter de l'utiliser.

Pour ne pas utiliser un logiciel comme exemple, disons que votre aspirateur fonctionne très bien sur une moquette ordinaire.

Il nettoie toute la poussière et les poils de chat. Une nuit fatidique, le chat renverse une plante, mettant de la terre partout.

Lorsque vous essayez d'utiliser l'aspirateur pour nettoyer le tas de saleté, il se brise et crache les résidus partout.

Bien que l'aspirateur ait fonctionné dans certaines circonstances, il n'a pas permis de gérer efficacement la charge supplémentaire occasionnelle.

 Ainsi, vous ne l'appelleriez pas un aspirateur de bonne qualité.

C'est un problème que nous voulons éviter dans notre code. Si les choses se cassent sur les bords et que les défauts provoquent un comportement indésirable, nous n'avons pas un produit de haute qualité.

Il est difficile à lire, à maintenir ou à étendre 

Imaginez ceci : un client demande une nouvelle fonctionnalité. La personne qui a écrit le code original a disparu.

La personne qui les a remplacés doit maintenant comprendre le code qui existe déjà. Cette personne, c'est vous.

Si le code est facile à comprendre, vous pourrez analyser le problème et trouver une solution beaucoup plus rapidement. Si le code est complexe et alambiqué, vous prendrez probablement plus de temps et ferez peut-être des suppositions erronées.

C'est aussi bien s'il est facile d'ajouter la nouvelle fonctionnalité sans perturber les fonctionnalités précédentes. Si le code n'est pas facile à étendre, votre nouvelle fonctionnalité pourrait casser d'autres choses.

Personne ne veut être dans la position où il doit lire, maintenir ou étendre un code de mauvaise qualité. Cela signifie plus de maux de tête et plus de travail pour tout le monde.

C'est déjà assez pénible d'avoir à faire face à un code de mauvaise qualité, mais ne mettez pas quelqu'un d'autre dans la même situation. Vous pouvez améliorer la qualité du code que vous écrivez.

Si vous travaillez avec une équipe de développeurs, vous pouvez commencer à mettre en place des méthodes pour assurer une meilleure qualité globale du code. En supposant que vous ayez leur soutien, bien sûr.

Il se peut que vous ayez à convaincre certaines personnes (n'hésitez pas à leur envoyer cet article 😃).

Comment améliorer la qualité du code python

Il y a quelques points à prendre en considération dans notre quête d'un code de haute qualité. Tout d'abord, ce voyage n'est pas un voyage de pure objectivité. Il y a des sentiments forts de ce à quoi ressemble un code de haute qualité.

Bien qu'on puisse espérer que tout le monde soit d'accord sur les identificateurs mentionnés ci-dessus, la façon dont ils sont atteints est une voie subjective. Les sujets les plus populaires sont généralement abordés lorsque vous parlez de lisibilité, de maintenance et d'extensibilité.

Gardez donc à l'esprit que bien que cet article tentera de rester objectif tout au long de l'article, il existe un monde très ouvert en ce qui concerne le code.

Alors, commençons par le sujet le plus populaire : le style de code.

Guides de styles

Ah, oui, oui. La question séculaire : espaces ou tabulations ?

Indépendamment de votre point de vue personnel sur la façon de représenter les espaces blancs, il est sûr de supposer que vous voulez au moins une cohérence dans le code.

Un guide de style sert à définir une façon cohérente d'écrire votre code. Typiquement, il s'agit de cosmétique, ce qui signifie que cela ne change pas le résultat logique du code. Cependant, certains choix stylistiques évitent les erreurs logiques courantes.

Les guides de style servent à faciliter la lecture, la maintenance et l'extension du code.

En ce qui concerne Python, il existe un standard bien accepté. Il a été écrit, en partie, par l'auteur du langage de programmation Python lui-même.
PEP 8 fournit des conventions de codage pour le code Python. Il est assez courant pour le code Python de suivre ce guide de style. C'est un bon point de départ puisqu'il est déjà bien défini.

PEP 257 décrit les conventions des docstrings de Python, qui sont des chaînes de caractères destinées à documenter les modules, classes, fonctions et méthodes. En prime, si les chaînes docstrings sont cohérentes, il existe des outils capables de générer de la documentation directement à partir du code.

Tout ce que ces guides font, c'est définir une façon de coder le style. Mais comment l'appliquer ? Et qu'en est-il des défauts et des problèmes dans le code, comment pouvez-vous les détecter ? C'est là que les linters entrent en jeu.

Linters

Qu'est-ce qu'un Linter ?

Parlons d'abord de peluches. Ces petits défauts minuscules et ennuyeux qui, d'une façon ou d'une autre, se retrouvent partout sur vos vêtements. 

Les vêtements ont l'air et se sentent beaucoup mieux sans toutes ces peluches. 

Votre code n'est pas différent. Les petites erreurs, les incohérences stylistiques et la logique dangereuse ne font pas de votre code une sensation agréable.

Mais nous faisons tous des erreurs. Vous ne pouvez pas vous attendre à les attraper toujours à temps.

Des noms de variables mal tapés, l'oubli d'un crochet de fermeture, une tabulation incorrecte en Python, l'appel d'une fonction avec un mauvais nombre d'arguments, la liste continue encore et encore. Les linters aident à identifier ces zones problématiques.

De plus, la plupart des éditeurs et des IDE ont la possibilité d'exécuter des linters en arrière-plan lorsque vous tapez.

Il en résulte un environnement capable de mettre en évidence, de souligner ou d'identifier les zones problématiques dans le code avant de l'exécuter. C'est comme une vérification orthographique avancée pour le code. 

Il souligne les problèmes dans les lignes rouges sinueuses tout comme votre traitement de texte favori le fait.

Les linters analysent le code pour détecter les différentes catégories de peluches. Ces catégories peuvent être définies au sens large comme suit :

  • Logical Lint
  • Erreurs de code
  • Code avec des résultats potentiellement involontaires
  • Modèles de codes dangereux
  • Touffes stylistiques
  • Code non conforme aux conventions définies

Il existe également des outils d'analyse de code qui fournissent d'autres informations sur votre code. Bien qu'ils ne soient peut-être pas des linters par définition, ces outils sont habituellement utilisés côte à côte avec les linters. Eux aussi espèrent améliorer la qualité du code.

Enfin, il existe des outils qui formatent automatiquement le code selon certaines spécifications. Ces outils automatisés assurent que nos esprits humains inférieurs ne perturbent pas les conventions.

Quels sont mes choix de Linter pour Python ?


Avant d'examiner vos options, il est important de reconnaître que certains "linters" ne sont que des linters multiples bien emballés ensemble. Quelques exemples populaires de ces combo-linters sont les suivants :

Flake8: Capable de détecter les peluches logiques et stylistiques. Il ajoute les contrôles de style et de complexité de pycodestyle à la détection logique des peluches de PyFlakes. Il combine les linters suivants :

  • PyFlakes
  • pycodestyle (formerly pep8)
  • Mccabe

Pylama: Un outil d'audit de code composé d'un grand nombre de linters et d'autres outils d'analyse de code. Il combine les éléments suivants :

  • pycodestyle
  • pydocstyle
  • PyFlakes
  • Mccabe
  • Pylint
  • Radon
  • gjslint

Voici quelques linters autonomes classés par catégories avec de brèves descriptions :

<table style="width: 458px;">
<tbody>
<tr style="text-align: center;">
<td style="width: 104px;">
<p><strong>Linter</strong></p>
</td>
<td style="width: 100.094px;">
<p><strong>cat&eacute;gorie</strong></p>
</td>
<td style="width: 234.906px;">
<p><strong>Description</strong></p>
</td>
</tr>
<tr style="text-align: center;">
<td style="width: 104px;">
<p><a href="https://www.pylint.org/"><span style="font-weight: 400;">Pylint</span></a></p>
</td>
<td style="width: 100.094px;">
<p><span style="font-weight: 400;">Logical &amp; Stylistic</span></p>
</td>
<td style="width: 234.906px;">
<p><span style="font-weight: 400;">V&eacute;rifie les erreurs, essaie d'appliquer une norme de codage, recherche les odeurs de code.</span></p>
</td>
</tr>
<tr style="text-align: center;">
<td style="width: 104px;">
<p><a href="https://github.com/PyCQA/pyflakes"><span style="font-weight: 400;">PyFlakes</span></a></p>
</td>
<td style="width: 100.094px;">
<p><span style="font-weight: 400;">Logical</span></p>
</td>
<td style="width: 234.906px;">
<p><span style="font-weight: 400;">Analyse les programmes et d&eacute;tecte diverses erreurs</span></p>
</td>
</tr>
<tr style="text-align: center;">
<td style="width: 104px;">
<p><a href="https://github.com/PyCQA/pycodestyle"><span style="font-weight: 400;">pycodestyle</span></a></p>
</td>
<td style="width: 100.094px;">
<p><span style="font-weight: 400;">Stylistic</span></p>
</td>
<td style="width: 234.906px;">
<p><span style="font-weight: 400;">V&eacute;rifications par rapport &agrave; certaines conventions de style dans PEP 8</span></p>
</td>
</tr>
<tr style="text-align: center;">
<td style="width: 104px;">
<p><a href="https://github.com/PyCQA/pydocstyle"><span style="font-weight: 400;">pydocstyle</span></a></p>
</td>
<td style="width: 100.094px;">
<p><span style="font-weight: 400;">Stylistic</span></p>
</td>
<td style="width: 234.906px;">
<p><span style="font-weight: 400;">V&eacute;rifie la conformit&eacute; avec les conventions de docstring Python</span></p>
</td>
</tr>
<tr style="text-align: center;">
<td style="width: 104px;">
<p><a href="https://github.com/PyCQA/bandit"><span style="font-weight: 400;">Bandit</span></a></p>
</td>
<td style="width: 100.094px;">
<p><span style="font-weight: 400;">Logical</span></p>
</td>
<td style="width: 234.906px;">
<p><span style="font-weight: 400;">Analyse le code pour trouver les probl&egrave;mes de s&eacute;curit&eacute; communs</span></p>
</td>
</tr>
<tr>
<td style="width: 104px; text-align: center;">
<p><a href="http://mypy-lang.org/"><span style="font-weight: 400;">MyPy</span></a></p>
</td>
<td style="width: 100.094px; text-align: center;">
<p><span style="font-weight: 400;">Logical</span></p>
</td>
<td style="width: 234.906px;">
<p style="text-align: center;"><span style="font-weight: 400;">Contr&ocirc;les des types statiques &eacute;ventuellement impos&eacute;s</span></p>
</td>
</tr>
</tbody>
</table>
<p>&nbsp;</p>
<p>&nbsp;</p>


Et voici quelques outils d'analyse de code et de formatage :



<table style="width: 456px;">
<tbody>
<tr>
<td style="width: 97px; text-align: center;">
<p><strong>Tool</strong></p>
</td>
<td style="width: 150.901px; text-align: center;">
<p><strong>cat&eacute;gorie</strong></p>
</td>
<td style="width: 190.099px; text-align: center;">
<p><strong>Description</strong></p>
</td>
</tr>
<tr>
<td style="width: 97px; text-align: center;">
<p><a href="https://github.com/PyCQA/mccabe"><span style="font-weight: 400;">Mccabe</span></a></p>
</td>
<td style="width: 150.901px; text-align: center;">
<p><span style="font-weight: 400;">Analytical</span></p>
</td>
<td style="width: 190.099px; text-align: center;">
<p><span style="font-weight: 400;">Regarder</span><a href="https://en.wikipedia.org/wiki/Cyclomatic_complexity"> <span style="font-weight: 400;">McCabe complexity</span></a></p>
</td>
</tr>
<tr>
<td style="width: 97px; text-align: center;">
<p><a href="http://radon.readthedocs.io/en/latest/"><span style="font-weight: 400;">Radon</span></a></p>
</td>
<td style="width: 150.901px; text-align: center;">
<p><span style="font-weight: 400;">Analytical</span></p>
</td>
<td style="width: 190.099px; text-align: center;">
<p><span style="font-weight: 400;">Analyse le code pour diverses m&eacute;triques (lignes de code, complexit&eacute;, etc.)</span></p>
</td>
</tr>
<tr>
<td style="width: 97px; text-align: center;">
<p><a href="https://github.com/ambv/black"><span style="font-weight: 400;">Black</span></a></p>
</td>
<td style="width: 150.901px; text-align: center;">
<p><span style="font-weight: 400;">Formatter</span></p>
</td>
<td style="width: 190.099px; text-align: center;">
<p><span style="font-weight: 400;">Formatage sans compromission</span></p>
</td>
</tr>
<tr>
<td style="width: 97px; text-align: center;">
<p><a href="https://github.com/timothycrosley/isort"><span style="font-weight: 400;">Isort</span></a></p>
</td>
<td style="width: 150.901px; text-align: center;">
<p><span style="font-weight: 400;">Formatter</span></p>
</td>
<td style="width: 190.099px; text-align: center;">
<p><span style="font-weight: 400;">Formate les importations en les triant par ordre alphab&eacute;tique et en les s&eacute;parant en sections.</span></p>
</td>
</tr>
</tbody>
</table>

Comparaison des Linters Python

Ayons une meilleure idée de ce que les différents linters sont capables de capturer et à quoi ressemble le résultat. Pour ce faire, j'ai passé le même code à travers une poignée de linters différents avec les paramètres par défaut.

Le code que j'ai entré dans les linters est ci-dessous. Il contient diverses questions logiques et stylistiques :

<iframe src="https://trinket.io/embed/python3/98b0805230" width="150%" height="450" frameborder="0" marginwidth="0" marginheight="0" allowfullscreen></iframe>


La comparaison ci-dessous montre les linters que j'ai utilisés et leur durée d'exécution pour analyser le fichier ci-dessus. Je dois souligner que tous ces éléments ne sont pas entièrement comparables, car ils servent à des fins différentes. PyFlakes, par exemple, n'identifie pas les erreurs stylistiques comme le fait Pylint.


<table>
   <tbody>
       <tr>
           <td>
               <p><strong>Linter</strong></p>
           </td>
           <td>
               <p><strong>Commande</strong></p>
           </td>
           <td>
               <p><strong>Time</strong></p>
           </td>
       </tr>
       <tr>
           <td>
               <p><a href="https://www.pylint.org/"><span style="font-weight: 400;">Pylint</span></a></p>
           </td>
           <td>
               <p><span style="font-weight: 400;">pylint main.py</span></p>
           </td>
           <td>
               <p><span style="font-weight: 400;">1.16s</span></p>
           </td>
       </tr>
       <tr>
           <td>
               <p><a href="https://github.com/PyCQA/pyflakes"><span style="font-weight: 400;">PyFlakes</span></a></p>
           </td>
           <td>
               <p><span style="font-weight: 400;">pyflakes main.py</span></p>
           </td>
           <td>
               <p><span style="font-weight: 400;">0.15s</span></p>
           </td>
       </tr>
       <tr>
           <td>
               <p><a href="https://github.com/PyCQA/pycodestyle"><span style="font-weight: 400;">pycodestyle</span></a></p>
           </td>
           <td>
               <p><span style="font-weight: 400;">pycodestyle main.py</span></p>
           </td>
           <td>
               <p><span style="font-weight: 400;">0.14s</span></p>
           </td>
       </tr>
       <tr>
           <td>
               <p><a href="https://github.com/PyCQA/pydocstyle"><span style="font-weight: 400;">pydocstyle</span></a></p>
           </td>
           <td>
               <p><span style="font-weight: 400;">pydocstyle main.py</span></p>
           </td>
           <td>
               <p><span style="font-weight: 400;">0.21s</span></p>
           </td>
       </tr>
   </tbody>
</table>

Pylint

Pylint est l'un des plus anciens linters (2006) et est toujours bien entretenu. Certains diront que ce logiciel est aguerri. Cela fait assez longtemps que les contributeurs ont corrigé la plupart des bogues majeurs et que les fonctionnalités de base sont bien développées.

Les plaintes courantes contre Pylint sont qu'il est lent, trop verbeux par défaut, et prend beaucoup de configuration pour le faire fonctionner comme vous le souhaitez. Lentement mis à part, les autres plaintes sont en quelque sorte une épée à double tranchant. La verbosité peut être due à la minutie.

Beaucoup de configuration peut signifier beaucoup d'adaptabilité à vos préférences.

Sans plus attendre, la sortie après avoir lancé Pylint contre le code rempli de lignes par le haut :

Aucun fichier de configuration n'a été trouvé, en utilisant la configuration par défaut


************* Module code_with_lint

W: 23, 0: Unnecessary semicolon (unnecessary-semicolon)

C: 27, 0: Unnecessary parens after 'return' keyword (superfluous-parens)

C: 27, 0: No space allowed after bracket

                return( 'an unlucky number!')

                      ^ (bad-whitespace)

C: 29, 0: Unnecessary parens after 'return' keyword (superfluous-parens)

C: 33, 0: Exactly one space required after comma

    def __init__(self, some_arg,  some_other_arg, verbose = False):

                               ^ (bad-whitespace)

C: 33, 0: No space allowed around keyword argument assignment

    def __init__(self, some_arg,  some_other_arg, verbose = False):

                                                          ^ (bad-whitespace)

C: 34, 0: Exactly one space required around assignment

        self.some_other_arg  =  some_other_arg

                             ^ (bad-whitespace)

C: 35, 0: Exactly one space required around assignment

        self.some_arg        =  some_arg

                             ^ (bad-whitespace)

C: 40, 0: Final newline missing (missing-final-newline)

W:  6, 0: Redefining built-in 'pow' (redefined-builtin)

W:  6, 0: Wildcard import math (wildcard-import)

C: 11, 0: Constant name "some_global_var" doesn't conform to UPPER_CASE naming style (invalid-name)

C: 13, 0: Argument name "x" doesn't conform to snake_case naming style (invalid-name)

C: 13, 0: Argument name "y" doesn't conform to snake_case naming style (invalid-name)

C: 13, 0: Missing function docstring (missing-docstring)

W: 14, 4: Redefining name 'some_global_var' from outer scope (line 11) (redefined-outer-name)

W: 17, 4: Unreachable code (unreachable)

W: 14, 4: Unused variable 'some_global_var' (unused-variable)

...

R: 24,12: Unnecessary "else" after "return" (no-else-return)

R: 20, 0: Either all return statements in a function should return an expression, or none of them should. (inconsistent-return-statements)

C: 31, 0: Missing class docstring (missing-docstring)

W: 37, 8: Redefining name 'time' from outer scope (line 9) (redefined-outer-name)

E: 37,15: Using variable 'time' before assignment (used-before-assignment)

W: 33,50: Unused argument 'verbose' (unused-argument)

W: 36, 8: Unused variable 'list_comprehension' (unused-variable)

W: 39, 8: Unused variable 'date_and_time' (unused-variable)

R: 31, 0: Too few public methods (0/2) (too-few-public-methods)

W:  5, 0: Unused import io (unused-import)

W:  6, 0: Unused import acos from wildcard import (unused-wildcard-import)

...

W:  9, 0: Unused time imported from time (unused-import)

Notez que j'ai condensé ceci avec des ellipses pour des lignes similaires. C'est un peu difficile à comprendre, mais il y a beaucoup de charpie dans ce code.

Notez que Pylint préfixes chacune des zones problématiques avec un R, C, W, E, ou F, ce qui signifie :

  • [R]efactor for a “good practice” metric violation
  • [C]onvention for coding standard violation
  • [W]arning for stylistic problems, or minor programming issues
  • [E]rror for important programming issues (i.e. most probably bug)
  • [F]atal for errors which prevented further processing

Voir le guide utilisateur

PyFlakes

Pyflakes "fait une promesse simple : il ne se plaindra jamais du style, et il essaiera très, très fort de ne jamais émettre de faux positifs". Cela signifie que Pyflakes ne vous dira pas s'il manque des chaînes de caractères ou des noms d'arguments qui ne sont pas conformes à un style de nommage. Il se concentre sur les problèmes de code logique et les erreurs potentielles.

L'avantage ici, c'est la rapidité. PyFlakes fonctionne en une fraction du temps que prend Pylint.

Sortie après l'exécution contre le code rempli de peluches par le haut :


code_with_lint.py:5: 'io' imported but unused

code_with_lint.py:6: 'from math import *' used; unable to detect undefined names

code_with_lint.py:14: local variable 'some_global_var' is assigned to but never used

code_with_lint.py:36: 'pi' may be undefined, or defined from star imports: math

code_with_lint.py:36: local variable 'list_comprehension' is assigned to but never used

code_with_lint.py:37: local variable 'time' (defined in enclosing scope on line 9) referenced before assignment

code_with_lint.py:37: local variable 'time' is assigned to but never used

code_with_lint.py:39: local variable 'date_and_time' is assigned to but never used


L'inconvénient ici est que l'analyse de cette sortie peut être un peu plus difficile. Les divers problèmes et erreurs ne sont pas étiquetés ou organisés par type. Selon la façon dont vous l'utilisez, cela peut ne pas être un problème du tout.

pycodestyle (qui était avant pep8)

Utilisé pour vérifier certaines conventions de style de PEP8. Les conventions de nommage ne sont pas vérifiées, ni les chaînes docstrings. Les erreurs et les avertissements qu'il capture sont catégorisés dans ce tableau.

---------

Output after running against lint-filled code from above:

code_with_lint.py:13:1: E302 expected 2 blank lines, found 1

code_with_lint.py:15:15: E225 missing whitespace around operator

code_with_lint.py:20:1: E302 expected 2 blank lines, found 1

code_with_lint.py:21:10: E711 comparison to None should be 'if cond is not None:'

code_with_lint.py:23:25: E703 statement ends with a semicolon

code_with_lint.py:27:24: E201 whitespace after '('

code_with_lint.py:31:1: E302 expected 2 blank lines, found 1

code_with_lint.py:33:58: E251 unexpected spaces around keyword / parameter equals

code_with_lint.py:33:60: E251 unexpected spaces around keyword / parameter equals

code_with_lint.py:34:28: E221 multiple spaces before operator

code_with_lint.py:34:31: E222 multiple spaces after operator

code_with_lint.py:35:22: E221 multiple spaces before operator

code_with_lint.py:35:31: E222 multiple spaces after operator

code_with_lint.py:36:80: E501 line too long (83 > 79 characters)

code_with_lint.py:40:15: W292 no newline at end of file

-------


Ce qu'il y a de bien avec cette sortie, c'est que la peluche est étiquetée par catégorie. Vous pouvez choisir d'ignorer certaines erreurs si vous ne souhaitez pas adhérer à une convention spécifique.

pydocstyle (avant pep257)

Très similaire à pycodestyle, sauf qu'au lieu de vérifier les conventions de style de code PEP8, il vérifie les docstrings par rapport aux conventions de PEP257.

sortie après exécution contre du code rempli de lignes par le haut :

-------

code_with_lint.py:1 at module level:

        D200: One-line docstring should fit on one line with quotes (found 3)

code_with_lint.py:1 at module level:

        D400: First line should end with a period (not '!')

code_with_lint.py:13 in public function `multiply`:

        D103: Missing docstring in public function

code_with_lint.py:20 in public function `is_sum_lucky`:

        D103: Missing docstring in public function

code_with_lint.py:31 in public class `SomeClass`:

        D101: Missing docstring in public class

code_with_lint.py:33 in public method `__init__`:

        D107: Missing docstring in __init__

--------

Encore une fois, comme pycodestyle, pydocstyle étiquette et catégorise les différentes erreurs qu'il trouve. Et la liste n'entre en conflit avec rien de pycodestyle puisque toutes les erreurs sont préfixées par un D pour docstring. Une liste de ces erreurs se trouve ici.

Coder sans Lint

Vous pouvez ajuster le code précédemment rempli de lignes en fonction de la sortie de la machine à écrire et vous obtiendrez quelque chose comme ce qui suit :

Ce code est non pelucheux selon les linters ci-dessus. Bien que la logique elle-même soit pour la plupart absurde, vous pouvez voir qu'à tout le moins, la cohérence est respectée.

Dans le cas ci-dessus, nous avons lancé linters après avoir écrit tout le code. Cependant, ce n'est pas la seule façon de vérifier la qualité du code.

Quand vérifier la qualité de son code ?

Vous pouvez vérifier la qualité de votre code :

  • Quand vous l'écrivez
  • Quand il est enregistré à l'arrivée.
  • Quand vous faites vos tests.

Il est utile d'avoir des linters qui se heurtent fréquemment à votre code. Si l'automatisation et la cohérence n'existent pas, il est facile pour une grande équipe ou un projet de perdre de vue l'objectif et de commencer à créer un code de qualité inférieure.

Cela se fait lentement, bien sûr. Une logique mal écrite ou peut-être du code avec un formatage qui ne correspond pas au code voisin. Avec le temps, toute cette peluche s'accumule. Éventuellement, vous pouvez vous retrouver coincé avec quelque chose qui est boguet, difficile à lire, difficile à réparer et une douleur à entretenir.

Pour éviter cela, vérifiez souvent la qualité du code !

Pendant l’écriture

Vous pouvez utiliser des linters lorsque vous écrivez du code, mais configurer votre environnement pour le faire peut prendre un peu plus de temps. Il s'agit généralement de trouver le plugin pour votre IDE ou l'éditeur de votre choix.

 En fait, la plupart des EDI ont déjà des linters intégrés.

Voici quelques informations générales sur Python linting pour différents éditeurs :

Avant de commit son code

Si vous utilisez Git, des crochets Git peuvent être configurés pour faire fonctionner vos linters avant de valider.

D'autres systèmes de contrôle de version ont des méthodes similaires pour exécuter des scripts avant ou après une action dans le système. Vous pouvez utiliser ces méthodes pour bloquer tout nouveau code qui ne répond pas aux normes de qualité.
Bien que cela puisse sembler drastique, forcer chaque bit de code à passer au crible les peluches est une étape importante pour assurer une qualité continue. L'automatisation du contrôle à la porte d'entrée de votre code pourrait être le meilleur moyen d'éviter le code rempli de lignes.

Quand vos faîtes des tests

Vous pouvez également placer les linters directement dans n'importe quel système que vous pouvez utiliser pour une intégration continue. Les linters peuvent être configurés pour échouer la compilation si le code ne répond pas aux normes de qualité.

Encore une fois, cela peut sembler une étape radicale, surtout s'il y a déjà beaucoup d'erreurs de linter dans le code existant.

Pour lutter contre cela, certains systèmes d'intégration continue vous permettront de n'échouer que si le nouveau code augmente le nombre d'erreurs linter qui étaient déjà présentes.

De cette façon, vous pouvez commencer à améliorer la qualité sans avoir à réécrire entièrement votre base de code existante.

Tu as bien aimé l'article ou tu as mal aux yeux :

Voici le PDF

Article écrit par :
Mikael Monjour
Data et Automatisation