Analyse du code de ZDS

Bonjour à tous !

Aujourd'hui j'ai fait tourner deux outils d'analyse du code pour ZDS, pycharm et pylint.

inspection du code par pycharm

Rapport complet

Le rapport complet se trouve ici (le https est fourni par un certif autosigné, donc désolé pour les utilisateurs de mobile).

Synthèse

• beaucoup d'erreur pep8
  • cela devrait se réduire petit à petit
  • je n'ai pas réussi à configurer pycharm pour ignorer les conventions pep8 qui nous ne voulons pas suivre
• nous ne désignons que rarement les exceptions à capter
• quelques problèmes de types
• pas mal de problèmes dans les templates (assets and co)
  • comme nous n'avons pas de problème à l'affichage je dirais que c'est pycharm qui bug, mais on ne sait jamais

inspection du code par pylint

Rapport complet

Le rapport complet se trouve ici (le https est fourni par un certif autosigné, donc désolé pour les utilisateurs de mobile).

Synthèse

• Beaucoup de dupplication ! : 30% du code est dupliqué !
  • devrait sûrement changer avec la ZEP 12
  • les tests contiennent énormément de duplication. Cela doit signifier que nous avons une réelle factorisation des tests à faire (je pense notamment à la publication d'un tuto) voire des tests plus précis à lancer
• missing-docstring 881

PyCharm pige pas tout à sa vie dans les templates, ais-je constaté, donc je laisserai ça sur le coté pour le moment (à priori, je vois pas de fautes là ou il les signale). Le PEP8, maintenant que firm1 a mis en ordre tout ça, on est censé le suivre, tout du moins à un certain niveau, donc ça va s'améliorer.

Par contre, pour les exceptions, gros +1. Et je suis sur qu'il y a encore des catch *: qui trainent dans le code (j'en ai déjà vu)

Pour ce qui est de la duplication de code dans les tests, faut voir aussi à quel point : y'a pas 36000 codes pour créer un tuto et j'avoue que je fais du copier coller de code d'un test à l'autre, parce que c'est pas forcément le but non plus (mais c'est peut-être mal, ceci dit) : si j'ai besoin d'une modif, ce sera le même self.client.post() pendant tout le test (exprès, d'ailleurs).

Pour les tests, c'est certain qu'on duplique mais c'est aussi normal et je pense pas qu'il faille s’inquiéter (et au pire plus il y a de tests et mieux c'est ).

Par exemple, parlons de la classe member que j'ai re-TU-iser il y a pas longtemps. J'ai procédé de la manière suivante, en m'inspirant des exemple de poulp et de divers articles sur le net:

• Dans le dossier zds/member
  • Ajout d'un dossier "tests"
    • Ajout d'un fichier tests_forms.py
    • Ajout d'un fichier tests_models.py
    • Ajout d'un fichier tests_views.py
  • Suppression du vieux fichiers test.py

Ensuite,

• dans le tests_forms.py : Je test tout les formulaires de forms.py, avec tout leur cas de figures possibles (tout les if/else) pour le clean et compagnie
• dans le tests_models.py : Je test toutes les méthodes de models.py. La encore tout les if/else
• Dans le tests_views.py : Je suis censé (pas fini) tester toutes les méthodes et les cas de figures.

On se doute bien que certains trucs vont se recouper, (si deux if/else se suive, on passera forcement deux fois dans le premier lors de tout les tests et au moins une fois dans le second. Une fois pour le tester, une fois pour tester le suivant).

beaucoup d'erreur pep8

Peut-être préciser la version du dépot (branche/commit) sur lequel tu lances ton analyse ?

Parce que normalement depuis le 09 septembre la branche de dev a été nettoyée des problèmes de pep8. Les seuls endroit ou on pourrait encore avoir du non pep8 sont spécifié ici, il s'agit :

• des fichiers de migrations south : c'est voulu
• des fichiers urls.py : voulu aussi
• du fichier des settings : voulu encore.

Donc, il faut que tu rajoute ces exceptions à ton PyCharm avant de relancer l'analyse, et n'oublie pas qu'on est sur une limite de 120 caractères en largeur.

Comme je l'ai dit pour pep8, c'est surtout parce que je n'ai aps encore réussi à configurer pycharm.

Pour la branche c'était celle où pierre_24 faisait de la doc pour la désinscription il me semble.

Je n'ai pas non plus trouvé un outil qui donne de vraies stats sur la maintenabilité et la complexité du code. Mais comme j'avais ces rapports là, je les ai donnés. Si ça peut servir à ne serait-ce qu'une personne, on prend.

Juste une question pratique pour quelqu'un qui ne connaît pas bien ces outils : est-ce-qu'il s'agit là juste d'une vérification "syntaxique" avancée (type Checkstyle) ou d'une analyse approfondie du code (type Findbugs : genre un handler de fichier qui potentiellement - la plupart du temps si une exception se produit - peut ne jamais être fermé) ?

pour pylint c'est plus un findbugs. Pour l'analyse par pycharm, je sais pas.