9.1 Les fonctions
À chaque fois que vous utilisez R vous employez des fonctions sans plus y porter attention comme la fonction mean()
par exemple. Vous pouvez cependant écrire vos propres fonctions qui seront adaptées à votre problématique. La règle est assez simple : si vous répétez des blocs de codes plus de deux ou trois fois, il faut réaliser une fonction.
L’utilisation de fonctions a plusieurs avantages :
On évite de répéter des blocs de codes plusieurs fois
On limite les possibilités de bug et leur correction ne doit être faite qu’à un seul endroit
On rend notre code plus lisible
Une fonction se présente comme ci-dessous :
La fonction porte un nom explicite suivi de parenthèses. À l’intérieur des parenthèses, on retrouve les arguments de la fonction.
Plusieurs fonction portant sur une même problématique se regroupe dans un package comme vous avez également l’habitude d’en utiliser comme {data.io}, {chart}, {knitr}. Néanmoins, ces notions ne seront pas détaillé au sein de ce module. Le package est très utile lorsque vous devez employer vos fonctions dans plusieurs projets différents. Il sera détaillé dans le module 12.
9.1.1 Nom de la fonction et de ses arguments
S’il y a bien une question qui va vous prendre la tête et qui requiert généralement un certain temps de réflexion c’est le nom de votre fonction et de ses arguments. Un nom mal choisi et/ou farfelu voue votre fonction à l’oubli. Il faut essayer d’avoir un nom court et évoquant le rôle de la fonction. Essayez de respecter la convention suivante qui veut que le nom d’une fonction soit un verbe et que ses arguments soient des noms. De plus, il est de plus en plus courant de respecter le “snake_case” (tout est en minuscule séparé par des sous-tirets)
Au final, vous verrez que R n’est pas homogène. R est un language qui évolue au cours du temps et ce depuis 1993, ce qui explique ce manque d’homogénéité. Cependant, restez cohérent, fixez vous vos propres conventions et respectez-les.
Imaginons que vous écrivez plusieurs fonctions :
-
CV()
-
Rescale01()
-
reg_lin()
-
TriMesTer()
-
MonIncroyable.fonction()
Ne faites pas cela ! Soyez cohérent dans le nommage et préférez soit le “snake_case” (tout en minuscule avec les mots séparés par des traits soulignés), soit le “camelCase” (mots accolés dont la première lettre est en majuscule, à l’exception du premier mot) sans mélanger ces deux formes.
-
ceci_est_du_snake_case
-
ceciEstDuCamelCase
Tout comme pour le nom des fonctions, le nom des arguments est important. Les arguments se doivent d’être clairs. Il existe néanmoins des conventions d’usage.
x
,y
,z
: vecteursw
: un vecteur de pondérations (w est le diminutif de weights)df
: un tableau de données (data frame)i
,j
: indice numérique (par exemple pour spécifier les colonnes et les lignes d’un tableau de données)n
: un nombre d’items dans un échantillon, un nombre de lignes dans un tableau, etc.p
: un nombre de colonnes dans un tableau…
Vous retrouverez en plus des arguments comme na.rm=
. Il s’agit également d’arguments conventionnels. Si vous avez le besoin d’éliminer les valeurs manquantes de vos calculs dans la fonction, ajoutez-lui cet argument. Ne le nommez pas autrement pour le plaisir, car les autres utilisateurs seront déboussolés par vos choix inhabituels. Par exemple, si vous avez opté pour le snake_case, réfrénez-vous à écrire na_rm=
. C’est, certes, plus cohérent par rapport à vos propres conventions, mais cela sort de la convention générale et la différence entre .
et _
est suffisamment subtile à la lecture du code pour que de nombreuses personnes ne le remarquent même pas et commettent ensuite une erreur !