Combien de fois faut-il recopier le même petit bout de calcul avant de sentir que quelque chose ne tourne pas rond ? Je ne saurais pas dire combien de fois j'ai fait ça avec un calcul de TVA, collé un peu partout dans un même script. Comme beaucoup de python débutantes qui avancent en auto-formation à leur table de cuisine, j'ai mis du temps à admettre qu'apprendre à coder, c'est aussi apprendre à ne pas se recopier soi-même. Les fonctions sont l'outil qui a changé ça pour moi.
Petite précision avant d'aller plus loin : ce carnet contient quelques liens affiliés. Si vous passez par eux pour un achat, je touche une petite commission, sans que le prix change pour vous. Je ne parle ici que d'outils que j'utilise vraiment à ma table de cuisine, comme la Formation au langage Python qui m'a servi de repère au tout début.
Le copier-coller, un raccourci qui se paie cher
Une voisine qui élève des abeilles sur son balcon m'avait conseillé, avec beaucoup d'assurance, de viser tout de suite un vrai projet pour rester motivée. J'ai suivi le conseil et je me suis lancée dans quelque chose de bien trop ambitieux avant même de savoir écrire une fonction correctement. Je l'ai abandonné assez vite, submergée. Ce qui a fini par marcher, c'est beaucoup plus modeste : un calcul de taxe recopié à la main sur mes courses, puis sur mes factures d'électricité, puis sur l'abonnement internet, un copier-coller après l'autre.
Le problème est arrivé le jour où j'ai voulu ajuster un détail dans ce calcul de taxe. Il a fallu modifier chaque bloc à la main, un par un, et l'un d'eux a fini par planter à cause d'une virgule oubliée dans une ligne dupliquée sans y prêter assez attention.
Ces lignes rouges qui s'accumulaient dans Visual Studio Code pour écrire mon code ne m'ont pas franchement aidée à garder le moral, certains soirs. C'est un classique du début : on croit gagner du temps avec un copier-coller rapide, puis on en perd bien plus à chercher une erreur de ponctuation cachée dans un double.
Écrire ses premières fonctions Python avec def
Tout commence par un mot-clé tout simple : def, suivi d'un nom et de parenthèses. C'est le signal donné à Python pour dire qu'on définit une action qu'on veut pouvoir réutiliser sans la retaper. Le corps de la fonction se place juste en dessous, légèrement décalé vers la droite — je ne vais pas détailler la règle d'indentation ici, ce sujet mérite son propre carnet, mais je m'appuie sur ce que recommande le guide de style PEP 8 plutôt que d'improviser à chaque fois. Dedans, on retrouve souvent des variables qui reçoivent ce que la fonction attend, parfois une boucle qui répète une action, une condition qui choisit entre deux chemins, ou une saisie demandée directement à la personne qui utilise le programme.
Le résultat s'est vu tout de suite sur mon calcul de taxe : au lieu de plusieurs blocs identiques éparpillés dans le fichier, il n'en restait plus qu'un seul, rangé en haut, que j'appelais par son nom chaque fois que j'en avais besoin. La Formation au langage Python m'a aidée à voir ça non pas comme une suite de commandes à retenir, mais comme une façon plus reposante de ranger sa pensée.
Que mettre dans une fonction, et que laisser dehors ?
Porté par cette petite victoire, je suis tombée dans l'excès inverse : transformer absolument tout en fonction, même une addition toute simple entre deux chiffres. Multiplier les fonctions qui en appellent d'autres, et qui utilisent elles-mêmes des dictionnaires Python imbriqués, rend le code difficile à suivre dès qu'un bug apparaît quelque part au milieu.
Il vaut parfois mieux laisser deux petits blocs presque identiques côte à côte si cela rend la lecture plus simple, plutôt que de construire une fonction unique et trop généraliste qu'on ne comprendra même plus soi-même après quelques jours. L'équilibre est là : repérer le moment où la répétition devient un vrai problème, sans pour autant sur-organiser un simple script de gestion de factures comme s'il fallait piloter une fusée.
Un return oublié change tout le résultat
Une fonction sans instruction return renvoie par défaut un objet vide, 'None', même si le calcul s'est bien déroulé à l'intérieur. Ça m'a valu une soirée entière à chercher pourquoi mes résultats affichaient ce mot au lieu d'un chiffre : la fonction faisait le travail demandé, mais le gardait pour elle au lieu de me le rendre. Le message d'erreur qui accompagne ce genre de souci fait moins peur une fois qu'on a pris l'habitude de le lire posément plutôt que de le fuir des yeux.
Je me redresse encore parfois sur ma chaise de cuisine, qui craque un peu sous le mouvement, pour relire un message d'erreur une deuxième fois avant de conclure quoi que ce soit. Ce réflexe a fini par payer : quand j'ouvre aujourd'hui un fichier .py que je n'ai jamais vu, j'arrive à suivre ce qu'il fait sans demander de l'aide à personne, et les fonctions bien nommées y sont pour beaucoup — un peu comme reconnaître une recette de famille rien qu'à la liste des ingrédients, même sans avoir la fiche sous les yeux.
Ce même principe s'applique ailleurs : une fonction peut tout aussi bien manipuler du texte, trier les éléments d'une liste selon leur position, ou être rangée dans un module qu'on importe d'un fichier à l'autre pour ne pas tout réécrire ; certaines encadrent même un calcul risqué dans un bloc try/except pour éviter que le script entier s'arrête net.
Une fonction qu'on relit sans s'y perdre
Rien de spectaculaire là-dedans : un script un peu plus court et plus facile à relire, mais pour une autodidacte qui avance à sa table de cuisine, ça reste une petite victoire qui donne envie de continuer. Si vous débutez aussi et que vos scripts ressemblent encore à un patchwork de copier-coller, il n'y a rien d'anormal à ça — c'est une étape que presque tout le monde traverse. Pour garder un fil directeur sans s'éparpiller, je continue de m'appuyer sur la Formation au langage Python, celle-là même qui m'a évité d'abandonner quand les fonctions imbriquées commençaient à me donner le tournis. Plus tard, j'irai peut-être jeter un œil du côté de la formation JavaScript, mais pour l'instant, Python et moi, on avance encore à petits pas.
Reste une question que je n'ai pas encore tranchée : à partir de combien de paramètres une fonction devient-elle plus difficile à lire qu'à écrire deux fois le même bout de code ? Pour l'instant, je n'ai pas de réponse toute faite — juste l'habitude de me la poser avant d'ajouter un bloc de plus.