Style de code R : guide pratique pour un code propre et lisible

Q: Faut-il utiliser le pipe natif |> ou le %>% de magrittr ?

Pour du nouveau code, préférez le pipe natif |> — il ne nécessite aucun package et constitue désormais la valeur par défaut du tidyverse (R 4.1+). Gardez %>% là où une base de code l’utilise déjà, ou quand vous avez besoin d’une fonctionnalité propre à magrittr comme le marqueur . à une position arbitraire. Les deux suivent la même disposition : un espace avant le pipe et un retour à la ligne après.

Q: <- ou = pour l’affectation en R ?

Utilisez <- pour affecter des variables, et réservez = aux arguments nommés de fonction. Les garder séparés rend l’affectation visuellement évidente — c’est ce qu’impose le assignment_linter() de lintr. Les deux ne sont pas totalement interchangeables au niveau supérieur d’un appel, si bien que la convention évite aussi des surprises subtiles.

Q: Quelle convention de nommage le guide de style tidyverse recommande-t-il ?

snake_case — des lettres minuscules, des chiffres et des tirets bas entre les mots (fit_model, n_users). Nommez les variables avec des noms et les fonctions avec des verbes, gardez des noms concis mais parlants, et évitez de masquer des noms de fonctions courants comme c, mean ou data.

Q: Comment formater automatiquement du code R pour respecter le guide de style ?

Installez styler et lancez styler::style_file("script.R") sur un fichier, style_dir() sur un dossier ou style_pkg() sur un package — ou utilisez son add-in RStudio pour reformater la sélection courante. Il réécrit l’espacement, l’indentation et l’affectation sur place, sans changer le comportement.

Q: Quelle est la différence entre styler et lintr ?

styler corrige le formatage automatiquement ; lintr signale les problèmes sans changer votre code. Utilisez styler pour appliquer l’espacement et l’indentation, puis lintr pour repérer ce que le formatage ne peut pas — noms médiocres, objets inutilisés, lignes trop longues, = utilisé pour l’affectation. Ils sont complémentaires et, ensemble, couvrent toute la boucle de style.

Nommage, espacement, pipes et les outils qui formatent automatiquement votre code R

Programming

Un guide pratique du style de code R — nommage, espacement et indentation cohérents, affectation, le pipe et longueur de ligne selon le guide de style tidyverse, plus styler et lintr pour formater et vérifier votre code automatiquement.

Auteur·rice

Alboukadel Kassambara

Date de publication

8 juillet 2026

Modifié

16 juillet 2026

Ce que vous allez apprendre

Les conventions de nommage qui rendent le code R lisible — snake_case, des noms pour les variables, des verbes pour les fonctions, des fichiers numérotés.
Les règles d’espacement et d’indentation qui valent la peine d’être mémorisées — autour des virgules, des opérateurs, des parenthèses et des accolades.
Faut-il utiliser <- ou =, " ou ', et comment disposer le pipe (|> et %>%).
Comment arrêter de styliser à la main : laissez styler reformater votre code et lintr signaler ce qui cloche — les deux montrés en action sur du vrai code.

Un style cohérent n’est pas de la pédanterie — c’est le moyen le moins coûteux de rendre le code lisible, relisable et facile à fusionner. Quand tout le monde sur un projet espace, nomme et indente de la même façon, les diffs restent petits, les bugs remontent plus vite, et vous cessez de gaspiller les commentaires de revue sur des espaces. La bonne nouvelle : vous n’avez presque rien à mémoriser, car deux packages appliquent et vérifient les règles à votre place.

Ce guide distille le guide de style tidyverse — le standard de facto pour R, sur lequel s’appuie désormais le guide de style R de Google — pour n’en retenir que les règles que vous utiliserez vraiment, puis confie leur application à styler et lintr.

Laissez les outils travailler

Avant les règles, faisons connaissance avec les deux packages qui rendent l’essentiel automatique. Vous les installez une fois :

install.packages(c("styler", "lintr"))

styler reformate votre code pour respecter les règles tidyverse — de façon non invasive, sans changer ce que le code fait. Il fournit un add-in RStudio (le moyen le plus simple de reformater une sélection), plus des fonctions pour styliser un fichier, un répertoire ou un package entier :

style_text() — reformate une chaîne de code (pratique pour les démos et les rapports).
style_file() — stylise un fichier .R, .Rmd, .Rnw ou .Rprofile.
style_dir() — stylise tous les fichiers R d’un répertoire.
style_pkg() — stylise le code source d’un package (ou usethis::use_tidy_style()).

lintr vérifie votre code et signale chaque endroit où il s’écarte du guide de style — il ne change rien, il signale. lintr::lint("script.R") analyse un fichier ; dans RStudio, les résultats apparaissent dans le panneau Markers. Ensemble, la paire couvre toute la boucle : styler corrige ce qu’il peut, lintr repère ce qui reste (nommage, objets inutilisés, lignes trop longues).

Nous reviendrons sur les deux — en exécution réelle — à la fin. D’abord, les règles qu’ils appliquent.

Nommer les choses

Objets : minuscules et `snake_case`

N’utilisez que des lettres minuscules, des chiffres et des tirets bas ; séparez les mots par _ (ce qu’on appelle le snake case). Les noms doivent être concis mais parlants — c’est difficile, mais ça en vaut la peine.

# Good
day_one
day_1
fit_model

# Bad
DayOne      # camelCase / PascalCase
dayone      # runs words together
first.day   # dots read like S3 methods or list access

Quelques habitudes qui rapportent :

Les variables sont des noms, les fonctions des verbes — n_users contient des données ; count_users() fait quelque chose.
Ne masquez pas les fonctions courantes. Nommer une variable c, mean, data ou df déroute les lecteurs (et parfois l’analyseur syntaxique).
N’entassez pas de données dans les noms. Si vous vous surprenez à écrire model_2018, model_2019, model_2020, tournez-vous plutôt vers une liste ou un data frame avec une colonne year.

Fonctions : utilisez des verbes

Une fonction fait quelque chose, alors nommez-la avec un verbe.

# Good
add_row()
permute()

# Bad
row_adder()
permutation()

Fichiers : parlants, `.R`, numérotés quand l’ordre compte

Les noms de fichiers doivent être parlants et se terminer par .R. Tenez-vous-en aux chiffres, aux lettres, à - et _ — pas d’espaces ni de caractères spéciaux.

# Good
fit_models.R
utility_functions.R

# Bad
fit models.R    # space
foo.r           # not meaningful, lowercase extension
stuff.r

Si les fichiers s’exécutent dans un ordre défini, préfixez-les par des chiffres ; complétez à gauche par un zéro dès que vous en attendez plus de neuf, pour qu’ils se trient correctement :

00_download.R
01_explore.R
02_clean.R
...
09_model.R
10_visualize.R

Tenté d’insérer 02a_recode.R plus tard ? Ça marche, mais il est généralement plus propre de prendre sur soi et de renuméroter. Dans chaque fichier, chargez tous les packages en tête, et découpez le corps en sections repérables d’un coup d’œil, délimitées par des lignes commentées de - ou = :

# Load data ------------------------------------------------

# Clean data -----------------------------------------------

# Plot data ------------------------------------------------

Espacement

L’espacement est là où vivent la plupart des désaccords de style — et là où styler vous épargne le plus de frappe. Les règles sont simples une fois posées noir sur blanc.

Virgules

Mettez un espace après chaque virgule, jamais avant — exactement comme à l’écrit.

# Good
x[, 1]

# Bad
x[,1]
x[ ,1]
x[ , 1]

Parenthèses

Pas d’espace à l’intérieur ni à l’extérieur des parenthèses pour un appel de fonction normal :

# Good
mean(x, na.rm = TRUE)

# Bad
mean (x, na.rm = TRUE)
mean( x, na.rm = TRUE )

En revanche, mettez bien un espace avant ( pour if, for et while, car ce ne sont pas des appels de fonction :

# Good
if (debug) {
  show(x)
}

# Bad
if(debug){
  show(x)
}

Opérateurs

Entourez la plupart des opérateurs infixes — <-, = (pour les arguments nommés), ==, +, -, *, /, &&, || — d’un seul espace :

# Good
height <- (feet * 12) + inches
mean(x, na.rm = TRUE)

# Bad
height<-feet*12+inches
mean(x, na.rm=TRUE)

Les exceptions — les opérateurs de haute priorité ou de « collage » — ne prennent aucun espace autour : ::, :::, $, @, [, [[, ^, :, et les -/+ unaires.

# Good
sqrt(x^2 + y^2)
df$z
x <- 1:10

# Bad
sqrt(x ^ 2 + y ^ 2)
df $ z
x <- 1 : 10

Espaces supplémentaires pour l’alignement

Ajouter des espaces supplémentaires est acceptable quand cela aligne = ou <- et améliore la lisibilité — mais n’ajoutez jamais d’espaces là où ils ne sont normalement pas permis.

# Good — aligned
list(
  total = a + b + c,
  mean  = (a + b + c) / n
)

# Also fine — unaligned
list(
  total = a + b + c,
  mean = (a + b + c) / n
)

Accolades et indentation

Les accolades définissent la hiérarchie la plus importante du code R, alors rendez cette hiérarchie facile à voir. Trois règles :

{ est le dernier caractère de sa ligne.
Le contenu du bloc est indenté de deux espaces.
} est le premier caractère de sa ligne (associé à else sur la même ligne que l’accolade fermante).

# Good
if (y == 0) {
  if (x > 0) {
    log(x)
  } else {
    message("x is negative or zero")
  }
} else {
  y^x
}

# Bad
if (y == 0)
{
    if (x > 0) {
      log(x)
    } else {
  message("x is negative or zero")
    }
} else { y^x }

Deux espaces — pas des tabulations, pas quatre. C’est la seule règle dont styler et lintr vous rebattront le plus les oreilles, alors laissez les outils s’en charger.

Lignes longues

Gardez des lignes d’environ 80 caractères. Quand un appel de fonction est trop long pour une seule ligne, donnez au nom de la fonction, à chaque argument et à la parenthèse fermante ) sa propre ligne — des arguments étroitement liés peuvent partager une ligne :

# Good
do_something_complicated(
  something = "that",
  requires  = many,
  arguments = "some of which may be long"
)

# Bad
do_something_complicated("that", requires, many, arguments,
                         "some of which may be long")

Pour une longue définition de fonction, indentez les arguments de continuation pour les aligner sur le premier :

# Good — arguments aligned under the first
long_function_name <- function(a = "a long argument",
                               b = "another argument",
                               c = "another long argument") {
  # body indented by two spaces, as usual
}

Affectation, guillemets, points-virgules

Quelques règles d’une ligne qui tranchent des débats récurrents :

Affectez avec <-, pas =. Réservez = aux arguments nommés de fonction. Cela garde l’affectation visuellement distincte du passage d’arguments.
Utilisez ", pas ', pour les guillemets. La seule exception est un texte qui contient lui-même des guillemets doubles, p. ex. 'A tag: <a href="...">'.
Pas de points-virgules. Ne terminez pas une ligne par ;, et n’utilisez pas ; pour empiler plusieurs instructions sur une ligne.

# Good
x <- 5
label <- "Text"

# Bad
x = 5
label <- 'Text'
x <- 5; y <- 6

Arguments et `return()`

Quand vous appelez une fonction, omettez les noms des arguments de données (vous les utilisez constamment) mais nommez toujours les arguments de détail que vous redéfinissez — et ne comptez jamais sur l’appariement positionnel au-delà du premier ou des deux premiers arguments :

# Good
mean(1:10, na.rm = TRUE)

# Bad
mean(x = 1:10, , FALSE)

Réservez return() aux retours anticipés ; sinon, laissez R renvoyer de lui-même la dernière expression évaluée :

# Good
abs_value <- function(x) {
  if (x < 0) {
    return(-x)     # early return, on its own line
  }
  x
}

add_two <- function(x, y) {
  x + y            # no needless return()
}

# Bad
add_two <- function(x, y) {
  return(x + y)
}

Une fonction appelée pour ses effets de bord (afficher, tracer, sauvegarder) devrait renvoyer son premier argument de manière invisible, afin qu’elle se compose encore dans un pipe :

print.url <- function(x, ...) {
  cat("Url: ", build_url(x), "\n", sep = "")
  invisible(x)
}

Le pipe

Depuis R 4.1, le langage dispose d’un pipe natif, |>, et c’est désormais la recommandation par défaut — aucun package requis. Le pipe de magrittr, %>%, est encore partout dans le code tidyverse existant et suit les mêmes règles de disposition, donc les deux sont montrés ici.

Utilisez un pipe pour mettre en valeur une séquence d’étapes appliquées à un seul objet. Mettez un espace avant le pipe et — sauf pour une ligne unique triviale — commencez une nouvelle ligne après lui, en indentant chaque étape suivante de deux espaces :

# Good — native pipe
iris |>
  subset(Species == "setosa") |>
  transform(area = Sepal.Length * Sepal.Width) |>
  head()

# Bad — everything crammed on one line
iris |> subset(Species == "setosa") |> transform(area = Sepal.Length * Sepal.Width) |> head()

Un pipe à une seule étape peut rester sur une seule ligne — mais s’il n’a pas vocation à grandir, un simple appel de fonction est souvent plus clair :

# All fine — pick the clearest
iris |> head()
head(iris)

Quand ne pas utiliser de pipe : si vous jonglez avec plus d’un objet à la fois, ou si un résultat intermédiaire mérite un nom informatif, brisez la chaîne et utilisez des variables nommées. Un pipe sert à raconter une histoire linéaire, pas à cacher de la complexité.

Formater automatiquement avec `styler`

Voici le gain. Vous n’avez pas à placer vous-même le moindre de ces espaces — styler::style_text() réécrit un extrait brouillon au style tidyverse. Ici, nous lui donnons du code délibérément mal formaté et affichons ce qu’il renvoie :

library(styler)

messy <- "x=c(1,2 ,3);   if(x>0){print( 'hi' )}"
style_text(messy)

x <- c(1, 2, 3)
if (x > 0) {
  print("hi")
}

Toutes les règles de ce guide sont appliquées d’un coup : = devient la flèche d’affectation <-, un espace suit chaque virgule, > reçoit des espaces autour, if reçoit un espace, les accolades reçoivent une indentation de deux espaces, et le point-virgule est supprimé. En pratique, vous appelleriez style_file("script.R") ou cliqueriez sur l’add-in RStudio pour reformater tout un fichier sur place.

Vérifier avec `lintr`

styler corrige le formatage ; lintr attrape ce que le formatage seul ne peut pas — noms douteux, variables inutilisées, lignes dépassant la limite de longueur, = utilisé pour l’affectation. Il signale ; il n’édite jamais. Pointez-le sur une chaîne (ou un fichier avec lint("script.R")) et lisez les résultats :

library(lintr)

lint(
  text = "VeryBadName = 1:10",
  linters = list(
    assignment_linter(),
    object_name_linter()
  )
)

<text>:1:1: style: [object_name_linter] Variable and function name style should match snake_case or symbols.
VeryBadName = 1:10
^~~~~~~~~~~
<text>:1:13: style: [assignment_linter] Use one of <-, <<- for assignment, not =.
VeryBadName = 1:10
            ^

Chaque ligne vous indique l’emplacement, la sévérité et la règle — ici, que = devrait être <- et que VeryBadName enfreint la convention snake_case. Branchez lintr dans un hook de pre-commit ou dans la CI, et le style cesse d’être quelque chose que les relecteurs surveillent à la main.

Foire aux questions

Faut-il utiliser le pipe natif |> ou le %>% de magrittr ?

Pour du nouveau code, préférez le pipe natif |> — il ne nécessite aucun package et constitue désormais la valeur par défaut du tidyverse (R 4.1+). Gardez %>% là où une base de code l’utilise déjà, ou quand vous avez besoin d’une fonctionnalité propre à magrittr comme le marqueur . à une position arbitraire. Les deux suivent la même disposition : un espace avant le pipe et un retour à la ligne après.

<- ou = pour l’affectation en R ?

Utilisez <- pour affecter des variables, et réservez = aux arguments nommés de fonction. Les garder séparés rend l’affectation visuellement évidente — c’est ce qu’impose le assignment_linter() de lintr. Les deux ne sont pas totalement interchangeables au niveau supérieur d’un appel, si bien que la convention évite aussi des surprises subtiles.

Quelle convention de nommage le guide de style tidyverse recommande-t-il ?

snake_case — des lettres minuscules, des chiffres et des tirets bas entre les mots (fit_model, n_users). Nommez les variables avec des noms et les fonctions avec des verbes, gardez des noms concis mais parlants, et évitez de masquer des noms de fonctions courants comme c, mean ou data.

Comment formater automatiquement du code R pour respecter le guide de style ?

Installez styler et lancez styler::style_file("script.R") sur un fichier, style_dir() sur un dossier ou style_pkg() sur un package — ou utilisez son add-in RStudio pour reformater la sélection courante. Il réécrit l’espacement, l’indentation et l’affectation sur place, sans changer le comportement.

Quelle est la différence entre styler et lintr ?

styler corrige le formatage automatiquement ; lintr signale les problèmes sans changer votre code. Utilisez styler pour appliquer l’espacement et l’indentation, puis lintr pour repérer ce que le formatage ne peut pas — noms médiocres, objets inutilisés, lignes trop longues, = utilisé pour l’affectation. Ils sont complémentaires et, ensemble, couvrent toute la boucle de style.

Aller plus loin dans `/learn`

Un style propre est le fondement ; l’étape suivante est de le mettre en œuvre sur du vrai code d’analyse. À voir :

ggplot2 : l’essentiel — construisez des graphiques prêts à publier avec un code lisible et cohérent.
Visualisation de données — le pilier complet de la visualisation.

Voir aussi

ggplot2 : l’essentiel — mettez un code propre en pratique. · Le guide de style tidyverse · styler · lintr.

🟢 Avec un agent IA

Demandez à Prova « reformate cette fonction R selon le guide de style tidyverse et dis-moi ce qui a changé » — elle répond avec du code que vous pouvez exécuter sur vos propres scripts. The runtime is the judge. Demander à Prova →

Cette page vous a-t-elle été utile ?

Citation

BibTeX

@online{kassambara2026,
  author = {Kassambara, Alboukadel},
  title = {Style de code R : guide pratique pour un code propre et
    lisible},
  date = {2026-07-08},
  url = {https://www.datanovia.com/blog/r-coding-style-guide},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

Kassambara, Alboukadel. 2026. “Style de code R : guide pratique pour un code propre et lisible.” July 8. https://www.datanovia.com/blog/r-coding-style-guide.