code_standard

Standards de code

Documentation

Les fonctions et les méthodes doivent être pourvues de docstring en anglais lorsque cela est nécessaire (quasiment tout le temps).

Découpage du code

Une méthode ou une fonction ne devrait pas 'être trop longue'. Une estimations potentielle de ce qui est trop long serait 30 lignes. Mais ce n'est qu'une estimation. L'important ici est de ce demander si la fonction ou méthode que l'on est en train d'écrire ne fait pas trop de chose et si on ne pourrait pas "sortir" des choses dans des sous méthodes ou des sous fonctions spécialisées.

Nommage des choses

Les nommages doivent être le plus clair et le plus précis possible. Utiliser un nom incompréhensible parce que c'est plus court comme cela n'est pas une chose permise.

Typage

Autant que possible la mise en place de déclaration de type est encouragée.

Tests

• les noms des tests doivent être explicite (test_01 ne convient pas alors test_i_can_create_a_maintenance_consumer oui).

• Un test doit le plus possible tester une chose et une seule. On essaiera donc de limiter au plus possible (voir d'arriver à 1) le nombre d'assert fait par test.

• les tests doivent être le moins possible redondant. Imaginons qu'on modifie la méthode de calcul de temps restant concernant les maintenances. Normalement on ne devrait avoir à modifier que quelques tests, ceux qui traitent explicitement de la méthode de calcul. Si tout les tests en rapport avec la maintenance vérifie que le calcul est bon, ce n'est pas correct, parce qu'il va falloir modifier tout les tests.

Dérivation et Mixins

Bien que l'héritage soit un concept puissant, avoir une trop grosse lignée d'héritage est un anti-pattern bien connu (le YoYo Problem ). On se limitera donc sur le nombre de classe parente.

Dans l'idéal, on se fixe comme limite 3 hors de la lignée Django. Un exemple de ce que l'on s'autorise sans problème :

• A(Classe Django) -- B -- C(Classe finale)

et voila ce que l'on s'autorise 'au maximum' :

• A(Classe Django) -- B -- C -- D(Classe finale)

Les Mixins sont également un façon intéressante de partager du code entre Classe. Django les utilise à foison. Une régle simple qui devra être respecter le plus possible est de n'utiliser les mixins que dans les classes finales et jamais dans des classes intermédiaires. Pour reprendre un exemple avec M1 et M2 comme mixins, voici ce qu'il ne faut pas faire :

• A(Classe Django) -- (B - M1 - M2) -- C(Classe finale)
• A(Classe Django) -- (B - M1) -- (C - M2) (Classe finale)

Et voici ce qui est permis :

• A(Classe Django) -- B -- (C - M1 - M2) (Classe finale)