Un script qui tourne et un script qu'on comprend encore des mois plus tard, ce n'est pas la même victoire. J'ai rouvert un vieux fichier Python de l'hiver dernier, un de mes tout premiers essais depuis que j'apprends en autodidacte, le soir, après le travail. À l'époque, mon code fonctionnait très bien. Ce soir-là, pourtant, j'ai mis un temps fou à retrouver ce que j'avais voulu faire, parce que j'avais appelé mes variables 'a', 'b1', 'temp' et 'donnee'. Un vrai champ de mines pour ma propre mémoire de débutante. Longtemps, j'ai cru que la lisibilité du code, ce fameux PEP 8 dont tout le monde parle, n'était qu'un vernis esthétique réservé aux développeurs pros. Ce soir-là, j'ai compris que c'était faux.
Le mythe qui ne tient pas la route : « si ça marche, c'est suffisant »
On se dit, en commençant, qu'un nom de variable n'est qu'un détail technique. Tant que l'interpréteur ne râle pas, pourquoi s'embêter à chercher mieux que 'a' ou 'x' ? J'ai cru ça pendant longtemps. Le problème, c'est que l'ordinateur n'est pas celui qui doit rouvrir le script trois mois plus tard, fatiguée, en essayant de se souvenir de ce qu'elle avait en tête ce jour-là.
C'est là que la PEP 8 est entrée dans ma vie, croisée un peu par hasard au fil de mes recherches de débutante. Le nom me faisait d'abord penser à une norme de tuyauterie industrielle ou à un formulaire administratif compliqué. En réalité, c'est un guide de style pour écrire du Python, un genre de savoir-vivre entre développeurs. L'idée centrale : le code se relit bien plus souvent qu'il ne s'écrit, alors autant qu'il reste agréable à l'œil et compréhensible, même pour une autodidacte qui avance seule, sans personne pour relire par-dessus son épaule.
PEP 8, c'est quoi au juste pour une débutante autodidacte ?
Techniquement, la PEP 8 — Python Enhancement Proposal numéro 8 — a été écrite en partie par Guido van Rossum lui-même, le créateur de Python. On pourrait dire que c'est le code de la route du langage. Une des premières règles que j'ai retenues, c'est la limite de 79 caractères par ligne. Sur le coup, ça m'a semblé complètement dépassé : on n'a plus des écrans minuscules. Mais en relisant un vieux script sur un petit écran, j'ai fini par comprendre l'intérêt. C'est comme une ligne dans un livre trop large : l'œil se perd en revenant au début de la ligne suivante.
Le plus gros morceau, pour moi, reste le nommage. La PEP 8 recommande le 'snake_case' : tout en minuscules, les mots séparés par des underscores. Plutôt que 'listeinventaire' ou 'ListeInventaire', on écrit 'liste_inventaire'. Ça respire, ça se lit sans effort. Petit à petit, j'ai arrêté de voir ça comme une contrainte : c'est devenu presque un réflexe, une étiquette propre posée sur chaque variable, comme sur un bocal bien rangé dans un placard de cuisine.
Faut-il nommer ses variables en anglais ou en français ?
Vient alors une question qui m'a longtemps tiraillée : écrire mes noms de variables en anglais ou en français ? La PEP 8 recommande l'anglais pour les projets destinés à être partagés. Pour une débutante qui apprend seule le soir, ça a d'abord été un obstacle de plus. J'hésitais entre 'user_age' et 'age_utilisateur', sans savoir laquelle des deux allait vraiment m'aider à me relire plus tard. Parfois, j'utilise Python pour des choses toutes simples, comme quand je cherchais comment utiliser la fonction len en python pour compter ses éléments dans une liste de courses, et dans ces moments-là, 'nombre_articles' me parle bien plus que 'item_count'.
J'ai voulu bien faire et j'ai attaqué un manuel entièrement en anglais, en me disant que ça m'obligerait à prendre de bonnes habitudes dès le départ. Mauvaise idée : le vocabulaire technique était bien au-dessus de mon niveau du moment, et je passais plus de temps à traduire chaque phrase qu'à suivre la logique du code. J'ai refermé ce manuel sans regret. Depuis, je reste sur un français propre pour mes scripts personnels, en respectant scrupuleusement le format snake_case. Si je commence à mélanger les langues dans un même fichier, c'est là que le chaos s'installe vraiment.
Le piège du nom qui ne dit rien
Le piège classique, et il arrive encore d'y retomber un peu, c'est d'utiliser un mot fourre-tout comme 'temp' pour tout ce qui traîne : une température, un fichier temporaire, une valeur de passage qu'on compte supprimer plus tard. Le code tourne très bien, jusqu'au jour où deux 'temp' se marchent dessus dans le même bloc, et plus personne ne sait lequel est lequel.
Une variable doit dire ce qu'elle contient, pas ce qu'elle est techniquement pour l'ordinateur. 'temp' ne raconte rien. 'temperature_four' et 'fichier_temporaire_resultats' racontent une histoire, même relus à froid. Ça rejoint un peu ce que j'ai appris en même temps sur comment trier une liste en python sans tout mélanger : un nom impeccable ne sauve rien si la logique derrière reste brouillonne. Les deux doivent avancer ensemble.
La clarté compte plus que la brièveté
Mon astuce principale, celle qu'on ne trouve pas forcément dans les tutoriels les plus stricts, c'est que la PEP 8 n'est pas une loi absolue à suivre à la lettre. La règle dit de rester court, mais si la clarté demande un nom un peu long comme 'liste_invites_confirmation_recue', je le garde. Je préfère perdre quelques caractères que perdre dix minutes de réflexion plus tard, celle qui relira ce fichier sans aucun souvenir du contexte.
La première fois que j'ai écrit une boucle for sans rouvrir mes notes, et que le script a tourné du premier coup, j'ai mis de longues secondes à réaliser que ce n'était pas de la chance : c'est juste que mes variables s'appelaient enfin ce qu'elles étaient vraiment. Mon stylo, qui avait tapoté le bord de mon cahier de brouillon pendant que je cherchais le bon mot, s'est arrêté net. Ça m'a servi aussi quand j'ai commencé à découvrir l'automatisation réseau avec python pour simplifier ses tâches : sans noms explicites, on se perd vite entre les adresses IP et les configurations.
Reprendre son vieux code sans grimacer
Un ami qui file en trail dans la Chaîne des Puys presque chaque week-end m'a dit un jour que la préparation compte plus que la performance du jour même. Pour le code, c'est pareil : le nommage, c'est la préparation. Personne ne voit l'effort sur le moment, mais c'est lui qui évite de tout recommencer plus tard.
Aujourd'hui, quand je rouvre un vieux fichier, je regarde d'abord les noms avant même de relire la logique : si je comprends ce que fait chaque variable sans avoir à exécuter le script, c'est bon signe. Si je dois deviner, je sais qu'il faudra tout renommer avant d'aller plus loin. C'est une règle simple, presque bête, mais elle évite bien des soirées perdues. La prochaine étape, pour moi, c'est de m'attaquer à comment comprendre la différence entre liste et tuple en python simplement, parce qu'un bon nom de variable ne sert pas à grand-chose si je ne sais même pas quel type de donnée je manipule derrière. Est-ce qu'une liste et un tuple méritent vraiment des noms différents dans ma logique, ou juste dans ma tête ? Je verrai bien.