Ma tisane à la verveine est devenue tiède, presque froide, et mes yeux commencent à piquer sérieusement. Je suis assise à ma table de cuisine à Clermont-Ferrand, celle-là même où je prends mon petit-déjeuner en quatrième vitesse le matin, mais ce soir, elle s'est transformée en poste de combat contre un script récalcitrant. Le contact froid de la table en formica sur mes avant-bras et le ronronnement du réfrigérateur qui semble se moquer de mon code sont les seuls bruits dans l'appartement. Je fixe mon écran, et plus précisément une ligne rouge qui semble me narguer depuis dix minutes.
Apprendre le langage Python après une journée de boulot, c'est un peu comme essayer de monter un meuble complexe sans la notice et avec une seule main. On a envie que ça marche tout de suite, on a une idée précise de ce qu'on veut obtenir, et paf : le programme s'arrête net avec un message d'erreur long comme le bras. Un mardi soir de février, j'ai failli tout envoyer valser. J'essayais simplement de trier une liste de courses, et Python me répondait avec des mots que je ne comprenais pas, comme s'il me parlait en ancien norrois.
La règle d'or : On commence par la fin
Au début de mon apprentissage, il y a environ huit mois, ma première réaction face à une erreur était la panique. Je lisais le message de haut en bas, mot à mot, m'embrouillant dans les chemins de fichiers obscurs et les références à la version 3.12 de Python que j'avais installée. C'était épuisant. Et puis, un soir, j'ai eu un déclic : la réponse n'est presque jamais au début. C'est l'astuce que je donnerais à n'importe qui : ignorez les premières lignes du message d'erreur (ce qu'on appelle le Traceback).
En Python, les messages d'erreur se lisent à l'envers. La toute dernière ligne, c'est le nom du coupable. C'est là qu'on trouve l'explication « humaine » : une faute de frappe, un fichier introuvable, ou un calcul impossible. Les lignes au-dessus ne sont que le carnet de route du crash. En sautant directement à la fin, on s'épargne une fatigue mentale énorme. C'est un peu comme lire la fin d'un polar quand on est trop stressé par l'intrigue : on respire mieux tout de suite.
Le drame du « prnit » et la fatigue du soir
Après environ trois mois de pratique, j'ai réalisé que mes plus gros blocages ne venaient pas de la complexité de l'algorithme, mais de mes propres doigts fatigués. Je me souviens d'avoir passé deux heures à chercher une erreur complexe pour réaliser que j'avais écrit 'prnit' au lieu de 'print'. Deux heures. J'avais vérifié mes boucles, mes variables, mes imports... tout, sauf l'évidence. C'est là que j'ai compris que le débogage, c'est 90 % d'attention aux détails et 10 % de logique.
Pour éviter ça, j'ai commencé à utiliser des outils tout simples. Par exemple, j'essaie de respecter la limite de caractères PEP 8 qui conseille de ne pas dépasser 79 caractères par ligne. Pourquoi ? Parce que quand une ligne est trop longue, mes yeux fatigués de la journée sautent des morceaux. En gardant un code aéré, je vois mieux mes bêtises. Parfois, je m'aide aussi en allant consulter la documentation ou des exemples simples quand je sens que je m'emmêle les pinceaux.
Le canard en plastique version cuisine
Pendant les vacances de Pâques, j'ai testé une méthode dont tout le monde parle sur les forums : le « Rubber Duck Debugging ». Sauf que je n'ai pas de canard en plastique. Alors, j'ai pris ma salière. Le principe est bête comme chou : vous expliquez votre code, ligne par ligne, à un objet inanimé. « Alors là, ma petite salière, je demande à l'utilisateur de taper son nom avec la fonction input... ».
C'est magique. En forçant mon cerveau à verbaliser ce que j'ai écrit, je repère tout de suite l'endroit où je divague. C'est comme ça que j'ai réalisé que j'avais oublié deux points à la fin d'un 'if'. C'est une erreur classique, mais quand on la lit dans sa tête, on « voit » ce qu'on voulait écrire et non ce qui est réellement écrit. La salière, elle, ne ment pas. Si vous voulez essayer de rendre vos scripts un peu plus vivants, j'avais d'ailleurs écrit un petit texte sur comment utiliser la fonction input python pour créer un programme interactif, ce qui est souvent là que les erreurs commencent à arriver.
L'obsession des quatre espaces
S'il y a bien une chose qui peut rendre chèvre le soir, c'est l'indentation. En Python, l'indentation standard Python est de 4 espaces. Ce n'est pas juste pour faire joli, c'est ce qui dit à l'ordinateur quel morceau de code va avec quel autre. Un espace de trop, ou un mélange entre les espaces et les tabulations, et c'est le drame : « IndentationError ».
Une fin de journée pluvieuse en juin, j'ai passé un temps infini sur une boucle qui refusait de s'arrêter. J'étais persuadée que ma logique était bonne. En fait, ma commande de sortie de boucle était décalée d'un tout petit cran vers la droite. Pour Python, elle faisait donc partie de la boucle au lieu d'être à l'extérieur. Depuis, quand je vois un message d'erreur que je ne comprends pas, ma première vérification est visuelle : est-ce que tout est bien aligné sur ces fameux 4 espaces ? C'est souvent là que se cache le loup.
Savoir fermer le capot
Ma dernière astuce, et sans doute la plus difficile à appliquer, c'est de savoir s'arrêter. Il y a un point de non-retour, vers 22h ou 23h, où le cerveau ne décode plus rien. On s'obstine, on s'énerve contre la machine, on se sent nulle. Dans ces moments-là, la meilleure technique de débogage n'est pas dans le code : elle consiste à fermer l'ordinateur portable d'un coup sec, à finir sa tisane et à aller dormir.
Le nombre de fois où j'ai trouvé la solution le lendemain matin en 30 secondes, juste en ouvrant mon fichier avant de partir au travail, est hallucinant. Le sommeil range les idées. On revient avec un œil neuf et l'erreur nous saute aux yeux comme si elle était écrite en néon. Pour éviter de se perdre dans des copier-coller interminables qui multiplient les risques d'erreurs, j'ai d'ailleurs commencé à apprendre à créer des fonctions python pour arrêter de copier-coller mes blocs de code partout. Ça demande un petit effort au début, mais quel gain de sérénité pour mes soirées !
Apprendre Python à mon rythme, sur le coin de ma table de cuisine, c'est une leçon d'humilité permanente. Chaque bug corrigé est une petite victoire contre la fatigue et contre soi-même. Ce n'est pas grave de ne pas comprendre tout de suite. Ce n'est pas grave si le message d'erreur fait peur. L'important, c'est de garder sa salière à portée de main et de ne jamais oublier que même les meilleurs ont commencé par écrire 'prnit'.