Les fonctions

Donner un nom à un traitement

Un feu tricolore écrit sans fonction répète la même séquence trois fois : éteindre les trois LEDs, en allumer une, attendre. Une fonction la décrit une fois.

typeRetour nomDeLaFonction(type parametre1, type parametre2) {
  // instructions
  return valeur;          // absent si le type de retour est void
}

loop() se lit maintenant comme la description du feu. Et la fonction garantit une propriété que le code recopié ne garantissait pas : à aucun instant deux feux ne sont allumés ensemble.

Un appel suspend la fonction appelante. Quand loop() exécute allumerSeul(VERT, 3000), l'exécution saute au début de allumerSeul, en parcourt les instructions, puis revient à la ligne suivante de loop(). C'est pourquoi loop() n'avance vers l'orange qu'une fois les trois secondes de vert écoulées.

Pour revenir au bon endroit, la carte range l'adresse de retour et les variables de la fonction dans une zone de la mémoire vive appelée la pile, qui grandit à chaque appel et se vide à chaque retour. Le chapitre Les fonctions et la pile du parcours C explique ce que chaque appel y réserve, le cadre, et quand ce cadre est rendu. Sur l'Uno, elle partage les 2 Ko de mémoire vive avec toutes les variables : des appels trop imbriqués la font déborder sur les données, sans message d'erreur.

Agir ou calculer

Deux sortes de fonctions coexistent, et les distinguer rend un programme plus facile à corriger.

Une fonction qui agit modifie l'état de la carte : elle allume, attend, envoie un message. Elle ne rend rien, et son type de retour est void.

Une fonction qui calcule reçoit des valeurs et en rend une autre par return, sans rien toucher d'autre. Sa réponse ne dépend que de ses arguments.

Une fonction qui répond par oui ou non

Une question dont la réponse est vrai ou faux mérite une fonction de type bool. Son nom se lit alors comme une question, et l'appel se glisse directement dans un if.

return valeur >= minimum && valeur <= maximum; est l'écriture directe. Un débutant écrit souvent if (...) { return true; } else { return false; }, qui fait exactement la même chose en quatre lignes : la condition est déjà la réponse.

Le passage par valeur

La mémoire rend la chose évidente. Pendant l'appel doubler(n), deux variables existent : n, qui appartient à setup(), et x, que l'appel vient de créer ailleurs en mémoire en y copiant 21. La multiplication agit sur x. À la fin de l'appel, x disparaît, et n n'a jamais été touché.

Pour qu'une fonction change une valeur, elle la rend, et c'est l'appelant qui l'affecte. Cette règle a une exception, et elle concerne les tableaux.

Passer un tableau

Un tableau n'est pas copié quand on le passe à une fonction : celle-ci reçoit seulement l'adresse de son premier élément, c'est-à-dire un pointeur, au sens du parcours C. Deux conséquences en découlent.

La fonction peut modifier les éléments du tableau de l'appelant, puisqu'elle travaille sur la même mémoire. Et elle ne connaît pas la taille du tableau : sizeof y mesure l'adresse, pas le tableau. D'où la règle : la taille voyage toujours avec le tableau, en second paramètre.

La figure montre ce que reçoit moyenne lors de l'appel moyenne(lectures, NB). Le paramètre valeurs n'est pas une copie des quatre lectures : c'est une case de deux octets qui contient l'adresse de lectures[0], d'où la flèche. Le paramètre n est une copie ordinaire du nombre 4.

Puisque la fonction reçoit l'adresse, elle peut aussi écrire dans le tableau de l'appelant. C'est la seule façon propre, sans passer par une variable globale, de faire modifier plusieurs valeurs par une fonction :

Le mot-clé const du paramètre de moyenne prend alors tout son sens : il annonce, et le compilateur le fait respecter, que la fonction se contente de lire.

Garder une valeur d'un appel à l'autre

Une variable locale naît à chaque appel et disparaît à la fin : une fonction ne se souvient de rien. Pour compter le nombre de fois où elle a été appelée, la tentation est de déclarer une variable globale. Le mot-clé static offre mieux.

Le compteur ne peut donc être modifié que par prochainNumero, et aucune autre partie du programme ne risque de le remettre à zéro par erreur. C'est la bonne place pour une valeur qui n'intéresse qu'une fonction : le dernier état d'un bouton, l'instant du dernier clignotement, un numéro de message.

Réécrire un programme en fonctions

Un signal de détresse en morse, SOS, se compose de trois points, trois traits, trois points. Le code morse fixe tout en unités de temps : un point dure 1 unité, un trait 3, l'extinction entre deux signaux d'une même lettre 1, entre deux lettres 3, et entre deux messages 7.

Écrit d'un seul tenant, ce programme aligne dix-huit digitalWrite et autant de delay, et une erreur d'une unité ne se retrouve qu'en recomptant tout. Découpé en fonctions, il se lit comme la définition du morse :

Trois bénéfices, que la version recopiée n'avait pas.

• loop() dit ce que fait le programme : S, O, S, une pause. Le détail des durées est descendu d'un niveau.
• Chaque règle du morse est écrite une seule fois. Changer UNITE à 100 accélère tout le message sans risque d'oublier un delay.
• Chaque fonction se vérifie seule. point() produit « 1 0 » sur le chronogramme, lettreS() produit « 1 0 1 0 1 0 0 0 » : le chronogramme complet se retrouve en mettant bout à bout ces morceaux.

Mettre en pratique