Les stratégies de debuggage possibles

L'utilisation d'un debuggeur n'est que l'une des solutions devant un programme qui ne marche pas, elle doit s'inscrire dans la démarche suivante :

• Les différentes parties fonctionelles du programme doivent être au maximum testées indépendamment les unes des autres avant d'être utilisées ensembles, et ce dès que leur écriture est finie et même pendant, car c'est toujours plus difficile de comprendre le problème 2 mois après avoir écrit le code. Surtout, cela permet de localiser la source d'un problème, ce qui est le seul objectif du debuggage (il est évident que le meilleur debuggeur du monde ne corrige pas un bug, il permet juste de le localiser le plus rapidement possible).
• Avant de se lancer dans le suivi ligne par ligne de l'exécution du programme, il est préférable d'utiliser des printf placés aux endroits clés qui permettront de dire en gros ce qui ne va pas et à quel moment, ainsi on cherche au bon endroit et on économise 90% du temps et même dans bien des cas l'utilisation d'un debuggeur. Les dispositions suivantes sont particulièrement efficaces (et utilisées professionnellement):
  • La définition de niveaux de débuggage : le programme reconnait une option -d n sur sa ligne de commande où n est un niveau de debuggage qui contrôle l'activation des printf traceurs. Ainsi -d0 permettra de tester le programme sans affichage parasite tandis que -d3 permettra de suivre en détail le cheminement de l'exécution et affichera le contenu des variables importantes. Ceci ne remplace pas le debuggage ciblé, mais permet une vue globale de l'apparition du problème en séparant les manifestations visibles de ce problème de sa source par un diagnostic le plus en amont possible.
  • La vérification systématique des codes de retours des fonctions ANSI, qui signalent quand un des paramètres qui leur est passé est incorrect, couplé à l'appel de la fonction perror qui affiche un texte standard décrivant la dernière erreur survenue, celle dont le numéro est dans la variable globale errno, c'est cette fonction que l'on voit à l'oeuvre quand une commande unix répond No such file or directory par exemple.
• Enfin, et presque en dernier recours, mais il ne faut pas non plus chercher à tout prix à l'éviter, on peut utiliser un débuggeur, en l'occurence gdb ou xxgdb sa version graphique sous unix. La raison pour laquelle on limite le recours au débuggeur c'est qu'il suppose de modifier la compilation pour inclure dans l'exécutable des informations qui permettront de mettre un nom sur les variables et de faire correspondre un numéro de ligne dans un fichier C à un morceau de langage machine. Cela augmente considérablement la taille du programme et ralentie donc le cycle de développement, heureusement, avec les machines puissantes actuelles c'est un inconvénient mineur, mais pas pour le PB 190.