Le débogage est une étape très importante et fastidieuse. Elle permet de trouver et de corriger les bugs du programme. De nombreux outils sont à notre disposition pour nous aider mais le débogage reste encore une tâche difficile.
En programmation, il existe trois types d’erreurs possibles :
- Les erreurs de syntaxe
- Les erreurs d’exécution
- Les erreurs de logique
Une erreur de syntaxe naît de la mauvaise orthographe d’une commande. Si vous tapez INTEGEER au lieu de INTEGER, VB.NET n’a aucune idée de ce que INTEGEER signifie et il n’essaye même pas d’exécuter le reste du programme. Les erreurs de syntaxes sont affichées dans la liste d’erreurs. Lorsque VB.NET rencontre une erreur de syntaxe, il met gentiment dans la liste d’erreurs le mot mal orthographié pour vous montrer exactement quel est le problème. Il suffit donc de corriger l’orthographe de la commande et d’exécuter à nouveau le programme. Il suffit d’une seule erreur de syntaxe pour empêcher le programme de s’exécuter. Lorsque votre programme s’exécute finalement pour la première fois, vous savez que le programme ne possède aucune erreur de syntaxe.
Une erreur d’exécution est plus subtile qu’une erreur de syntaxe car elle ne se produit que lorsque votre programme reçoit des données qu’il n sait pas vraiment gérer. Un programme peut être truffé d’erreurs d’exécution, vous ne le saurez pas tant que vous n’avez pas exécuté le programme. Pour déclencher une erreur d’exécution dans votre propre vie, allez au MacDo et, lorsque l’employé vous demande ce qu’il peut faire pour vous, commander une crêpe. Du fait que l’employé attend de vous que vous commandiez quelque chose qui fait partie du menu des MacDo, il ne saura pas vous répondre et il est probable qu’il s'en suivra une erreur d’exécution. (C’est une image mais c’est compréhensible).
Sachez que même les grands programmes (MSN et autres) comportent des bugs qui sont des erreurs d’exécution. Il est impossible de créer un gros programme sans aucune erreur. Les programmeurs professionnels utilisent des méthodes permettant d'anticiper, détecter et corriger le plus d'erreurs possibles.
Le type de bugs le plus délicat est dû à une erreur de logique. Une erreur de logique se produit lorsque le programme ne fonctionne pas correctement parce que vous lui avez fourni de mauvaises commandes. Par exemple, si vous avez des enfants adolescents, demander leur de ranger leur chambre ou de faire la vaisselle. Ils s’acquitteront de la tâche mais pas forcément de la façon prévue. Au lieu de bien nettoyer les assiettes, ils vont peut-être seulement les mettre sous l’eau froide, ou alors mettre tout leur boxon sous leurs lits… Dans ces deux situations, l’adolescent a suivi vos instructions. Vos instructions n’étaient tout simplement pas assez précises ! Un ordinateur n’est pas très différent d’un adolescent !? (douteux). S’il peut trouver une échappatoire à vos instructions, il ne s’en privera pas ! Le problème est que comme vous pensez que vous avez donné à l’ordinateur la bonne marche à suivre, vous n’avez aucune idée de pourquoi le programme ne fonctionne pas. Il faut maintenant trouver l’endroit où les instructions ne sont pas assez précises et claires. Dans le cas d’un grand programme, vous avez éventuellement à le relire entièrement ligne par ligne (quel plaisir).
Etant donné que les bugs sont inévitables et en plus invisibles à l'oeil nu, il faut pouvoir les détecter puis comprendre ce qui les a provoqués afin de pouvoir les corriger. Une fois le bug localisé, il suffit de le corriger mais attention en corrigeant un bug vous pouvez en avoir créés d’autres ! Donc je vous conseille vivement de réécrire la partie du code qui contient le bug. En d’autres termes, le débogage est loin d’etre une tâche facile.
Trouver l’endroit où se cache le bug est la partie la plus difficile. Le moyen le plus simple est d’exécuter le programme ligne par ligne mais cela reste assez fastidieux. Imaginez que votre programme comporte 10 000 lignes de code, je vous vois mal examiner les lignes une par une ! Il faut donc utiliser d’autres méthodes. Il convient de regarder la partie du programme où vous pensez que le bug est susceptible d’agir. Par exemple, si votre fichier ne s’enregistre pas correctement, l’erreur se situe dans la partie du code qui traite de l’enregistrement du fichier.
Pour combattre les bugs, on peut mettre en place un piège à erreur. Un piège à erreur indique à l’ordinateur : voici un ensemble d’instructions génériques à suivre en cas de rencontre d’un problème que tu ne sais gérer. Ces instructions génériques et simples permettent d'afficher un message à l’écran. C’est toujours mieux que faire planter l’ordinateur !
Dans cet exemple, le programme va planter car la division par 0 n’est pas possible en mathématiques. Lorsque le programme va exécuter la ligne du calcul du résultat de la division, le code va passer immédiatement dans le Catch et afficher le message d’erreur. Par conséquent, la fonction CalculerPi ne sera pas exécutée. Vous comprenez donc que pour tester une partie de code, il suffit de l'insérer dans un bloc Try / Catch. Il ne vous reste plus qu’à gérer l’erreur en l’affichant.
Il existe d’autres méthodes pour intercepter les erreurs. Par exemple, Visual Studio fournit des outils de débogage. Le pas à pas consiste à exécuter le programme ligne par ligne en s’interrompant après chaque ligne. Vous pouvez alors voir ce que le programme a réalisé et étudier le code. Si le programme fonctionne bien de la façon dont vous le voulez, c’est que la ligne est correcte. Dans le cas contraire, il y a un bug que vous venez de découvrir. Pour traverser un programme pas à pas, appuyer sur F11 pour un pas à pas détaillé : la commande pas à pas détaillé traverse la totalité du programme ligne par ligne, y compris les lignes dans les procédures du programme. L’autre option est d’utiliser un pas à pas principal en appuyant sur F10 : Le programme traverse la totalité du programme mais à chaque fois que Visual Basic rencontre une procédure, il exécute toutes les instructions dans cette procédure sans vous obliger à visionner ligne par ligne la procédure (c’est donc plus rapide).
Les commandes pas à pas détaillé et pas à pas principal commencent l’exécution au début du programme et la poursuivent jusqu’à la fin. Pour des gros programmes, cette méthode devient fastidieuse et compliquée. Pour sauter certaines parties de votre programme dont vous savez déjà qu’elles fonctionnent, vous pouvez définir des points d’arrêt. Un point d’arrêt indique à Visual Basic d’exécuter le programme jusqu’à atteindre le point d’arrêt. Pour mettre en place un point d’arrêt rien de plus simple, cliquer à gauche de la ligne où vous souhaitez insérer une point d’arrêt. Visual Basic affiche un point rouge dans la marge de gauche pour vous montrer à quelle ligne correspond le point d’arrêt. Pour supprimer un point d’arrêt, cliquer de nouveau sur la ligne dans la marge. Si vous souhaitez supprimer tous les points d’arrêt d’un seul coup, aller dans le menu déboguer puis cliquer sur effacer tous les points d’arrêt.
La dernière méthode pour intercepter les bugs est l’espionnage de variables. Cette fonction est très utile. Elle permet de vérifier la valeur d’une variable à tout moment, comme ça vous pouvez contrôler la variable. Pour ajouter un espion, vous devez d’abord déboguer le programme. Ensuite sélectionner la variable et faites un clique droit puis sélectionner Ajouter un espion. L’espion apparaît dans la fenêtre des espions. Elle affichera la valeur de la variable à chaque instant.
Pour récapituler, pour combattre un bug, il faut le localiser, puis le détruire. Pour détruire les bugs, vous disposez du pas à pas (principal ou détaillé), des points d'arrêt (pour intercepter le code à un endroit précis), des espions (pour espionner des variables) et des pièges à erreurs (pour gérer des erreurs).
