Un programme qui ne donne pas le résultat attendu demande une enquête. Modifier plusieurs lignes au hasard peut masquer la cause et créer une autre erreur. Une démarche progressive permet de relier les observations à une hypothèse vérifiable.
1. Décrire précisément le résultat attendu
Choisissez une petite entrée et calculez son résultat à la main. Pour une somme, la liste [2, 4, 6] doit donner 12. Notez aussi ce que fait réellement le programme : une valeur fausse, un arrêt ou une absence de réponse sont des symptômes différents.
2. Reproduire le problème
Relancez avec les mêmes données et le même environnement. Relevez le message complet et l’endroit où l’erreur se manifeste. Si le résultat change, recherchez les éléments variables : données externes, ordre des opérations ou état conservé entre deux essais.
3. Réduire le programme
Retirez les éléments qui n’interviennent pas dans le problème, une étape à la fois. Gardez une copie du cas qui échoue. Un exemple minimal réduit le nombre d’hypothèses à examiner et permet à une autre personne de reproduire le comportement.
4. Observer les valeurs intermédiaires
Suivez les variables qui expliquent le résultat. Dans une boucle de somme, notez l’indice, la valeur lue et l’accumulateur avant puis après l’addition. Vérifiez que chaque élément attendu est visité et que l’initialisation correspond à l’opération.
5. Tester une hypothèse à la fois
Si la dernière valeur est ignorée, examinez la borne de la boucle. Ne changez pas en même temps la structure des données et toute la fonction. Une modification limitée permet de relier l’effet observé à la cause supposée.
6. Vérifier au-delà du premier exemple
Refaites le test initial, puis essayez un élément unique, une liste vide si elle est autorisée et des valeurs particulières. Conservez un test qui détecte le défaut corrigé. Expliquez ensuite la cause dans votre note de travail ou votre message de commit.
Un exemple de raisonnement
Pour chercher le maximum de [−8, −3, −5], initialiser le maximum à zéro produit une valeur absente de la liste. Si la liste est non vide, partir de son premier élément permet de comparer uniquement des candidats valides. Le cas vide demande une décision séparée et explicite.
Pour aller plus loin : préparer une question reproductible et s’entraîner à suivre une exécution.