La programmation défensive

La programmation défensive est un état d'esprit qui consiste à écrire son code de façon à s'attendre au pire. Le fait est que le programmeur peut insérer des fautes non détectées ou des inconsistances. Pour s'en prémunir, il faut prévoir un traitement pour les fautes : soit en ajoutant du code vérifiant l'état du système, soit par un traitement d'erreur classique. Dans l'idéal, il faudrait penser à toutes les sources d'erreurs possibles et prévoir un traitement pour chacune d'elles.

En outre, la programmation défensive permet de faire de la tolérance aux fautes. Elle a pour but d'empêcher l'apparition d'une défaillance en agissant sur les effets et non sur les causes. Un autre but de cette méthode est de pouvoir défendre le programme d'utilisateurs malveillants, en s'assurant par exemple que le fichier entré par l'utilisateur est bien valide.

Les erreurs les plus courantes :

» Valeur invalide ; exemple : valeur négative pour une durée ;
» Valeur extrême ; exemple : index de tableau négatif ou trop grand par rapport à la taille du tableau ;
» Boucles infinies ;
» Pointeurs invalides ;
» Erreur d'entrée/sortie : exemple : fichier absent ou vide ;
» Ecrasement de mémoire ;
» Mémoire non initialisée ;
» Pas de valeurs par défaut.

Un programme sale

Un programme est peu soigné quand :
» Le temps de compilation est anormalement long : pas d'utilisation des librairies, pas de techniques d'accélération, (etc.) ;
» Beaucoup de warnings de compilation sont présents : à ne pas ignorer ils peuvent cacher un bug ;
» La mémoire dynamique n'est pas libérée, cela peut engendrer des dysfonctionnements ;
» Des fichiers sources sont inclus dans le projet mais pas utilisés ;
» Des includes inutiles sont présents ou bien lorsqu'ils ne sont pas protégés contre l'inclusion multiple (par simple #ifndef) ;
» Des commentaires erronés sont présents, certainement en raison d'un copier-coller rapide ;
» Des lignes de code sont inutilisées ;
» Des librairies sont incluses dans l'édition des liens alors que l'on ne s'en sert pas ou bien des librairies en mode debug mélangées avec des librairies en mode release ;
» Des ressources sont inutilisées (images, menus, dialogues…).

Eléments de solutions

Nous avons vu les erreurs et les sources potentielles de ces erreurs et maintenant voici quelques astuces pour parvenir à les combattre. Elles consistent en de bons automatismes et en l'utilisation d'assertions.

Les bons automatismes permettent de ménager sa mémoire en appliquant des règles d'écriture.
» A chaque fois que l'on ouvre un fichier, une parenthèse ou une allocation, en réaliser la fermeture tout de suite après, et insérer le code entre les deux.

» Utiliser à peu près les mêmes noms de variable pour définir les mêmes objets.
» Au début d'une méthode, pour chaque paramètre de type pointeur, écrire une assertion vérifiant que le pointeur n'est pas nul, s'il est censé ne pas l'être.
» Ne pas supposer du fonctionnement d'une méthode ou d'une classe : lire la documentation.

Les assertions sont des points de vérification des propriétés fondamentales de l'objet. Un prédicat est placé dans un programme de façon à ce qu'il soit toujours vrai à cet endroit. Ainsi, une assertion correspond à une expression booléenne, que le développeur déclare devoir être vraie pour qu'une routine se lance. (Voir : Java : les assertions)