Les bonnes pratiques en programmation

Comme tous les domaines, la programmation a ses conventions. Certaines diffèrent d’un programmeur à l’autre, ou répondent à un cahier des charges défini par l’entreprise, mais d’autres sont universelles. Nous vous présentons ici ce qui est largement considéré comme les cinq commandements du programmeur.

Attention ! Nous vous demandons de lire cet article avec attention, et d’en assimiler le contenu. La qualité de votre code sera évaluée à chaque entretien avec l’enseignant !

Pourquoi des bonnes pratiques ?

Un code est un document destiné à être lu avant tout par des humains. On peut vouloir lire un code simplement pour comprendre comment certaines choses sont faites, ou pour le maintenir.

Lorsque l’on écrit du code, on devrait toujours garder en tête que :

  • Tout doit être simple à comprendre.
  • Les endroits à modifier pour apporter une modification doivent être faciles à identifier.
  • Il n’y a jamais trop de commentaires dans du code, il y a toujours trop de code dans les commentaires !

Les bonnes pratiques

Les quelques pratiques listées ci-dessous sont indispensables pour obtenir un bon code :

Pas d’optimisation prématurée

Lorsque l’on écrit du code, on doit toujours garder en tête que le plus important est la correction du code, c’est-à-dire qu’il doit donner un résultat correct.

Il est souvent utile d’avoir un code optimisé, et ce sera le cas dans le cadre du cours. Mais l’optimisation est une des dernières étapes dans l’écriture d’un programme.

Pourquoi optimiser en dernier ? Parce que tant que le code n’est pas correct, trouver les sources d’erreur est d’autant plus complexe que celui-ci n’est pas explicite.

Le code doit être structuré

Si à chaque fois que vous recevez un document, vous le jetez dans un grand sac avec tous les autres, vous allez peiner à le retrouver plus tard.

Pour un code c’est exactement pareil. Si vous voulez appliquer votre fonction non plus à x mais à 10+sqrt(x), faites-en une sous-fonction ! Et tant qu’à faire, donnez à cette sous-fonction un nom explicite qui vous aidera ensuite à comprendre à quoi elle sert.

Le code doit être factorisé

Oups ! Vous venez de vous rendre compte que vous avez oublié d’ajouter 1-y pour certains affichages de valeurs. C’est très simple à corriger puisque vous avez factorisé votre code !

On dit qu’un code est factorisé quand il n’y a pas de duplications de code excessives.

En pratique un bon codeur n’utilise jamais le copier-coller pour son code. Ce doit être un réflexe : toute répétition trop longue de code doit donner place à la définition d’une sous-fonction pour traiter ce problème. On rend alors la maintenabilité beaucoup plus simple. En plus, cela vous aidera peut-être aussi à mieux comprendre comment structurer votre code.

Pas de constantes mystérieuses

En relisant votre code, vous vous rendez compte que la variable z prend la valeur 1000 quand x != y. Mais pourquoi 1000 ?

Quand vous avez écrit ces lignes, il y a quelques semaines, tout était très clair dans votre tête. La constante 1000 représente l’infini dans votre problème. Mais maintenant que le temps est passé vous ne comprenez plus ce que vous avez fait.

Si vous avez besoin d’utiliser des constantes dans votre code, nommez-les ! Note : en général, on écrit les constantes en majuscules (par exemple INFINITY = 1000).

Les interfaces doivent être explicites

À quoi sert cette fonction inverse(x) ?

Les commentaires dans le code doivent être nombreux, bien plus nombreux en nombre de caractères que les lignes de code à proprement parler. En particulier, toutes les fonctions doivent être documentées : à quoi sert-elle, que sont les variables d’entrée et que retourne-t-elle ? N’hésitez pas à mettre d’autres notes : “à optimiser plus tard”, “ne fonctionne que si x est suffisamment petit” etc.

Exemple

Puisqu’un exemple vaut mille discours, voici un code simple en Python pour afficher le dixième nombre de Fibonacci. Le programme du haut donne un code ne respectant pas les bonnes pratiques de programmation, et celui du bas si.

Remarque : vous avez sûrement remarqué que le second programme est en Anglais. Préférez toujours cette langue pour vos noms de variables/fonctions ainsi que pour vos commentaires. En tant qu’ingénieur, vous serez amené(e) à travailler avec des personnes d’autres nationalités qui ne parleront pas forcément votre langue. En revanche (en général), l’Anglais parle à tout le monde !

Pour approfondir

Publié le

Laisser un commentaire