1)
Concernant les noms, je dirais même plus : il ne faut surtout pas être créatif, et utiliser le même mot même pour des objets de programmation différent. Par exemple en ocaml, l'espace des noms des type et des paramètres est séparé, il est donc souhaitable d'utiliser le même nom pour le type de la donné complexe et le paramètre des fonctions qui l'utilise.
2)
Pour la doc, il peut être souhaitable de maintenir à jour une spec en même temps que l'écriture du code et pointer sur les points de spec dans son code pour faire référence au niveau supérieur, cela évite de se noyer dans son code. Seul les points complexes ou non évident ont intérêt à être expliquer dans la doc.
3)
Une bonne métrique de la maintenabilité est le temps moyen de correction d'un bug (en gros <2h).
4)
C'est encore mieux si tes tests sont passées dans un outil de couverture de code, cela permet de voir ce qui a été oublié.
[^] # Re: C'est quoi propre ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du code propre, c'est quoi ?. Évalué à 2.
1)
Concernant les noms, je dirais même plus : il ne faut surtout pas être créatif, et utiliser le même mot même pour des objets de programmation différent. Par exemple en ocaml, l'espace des noms des type et des paramètres est séparé, il est donc souhaitable d'utiliser le même nom pour le type de la donné complexe et le paramètre des fonctions qui l'utilise.
2)
Pour la doc, il peut être souhaitable de maintenir à jour une spec en même temps que l'écriture du code et pointer sur les points de spec dans son code pour faire référence au niveau supérieur, cela évite de se noyer dans son code. Seul les points complexes ou non évident ont intérêt à être expliquer dans la doc.
3)
Une bonne métrique de la maintenabilité est le temps moyen de correction d'un bug (en gros <2h).
4)
C'est encore mieux si tes tests sont passées dans un outil de couverture de code, cela permet de voir ce qui a été oublié.
"La première sécurité est la liberté"