Syntaxe Flashcards
Noms d’objets
Les noms variables et fonctionnels doivent utiliser uniquement des minuscules, des nombres et . Utilisez des soulignements () (ce qu’on appelle le cas de serpent) pour séparer les mots dans un nom.__
Good
day_one
day_1
Bad
DayOne
dayone
Virgules
Mettez toujours un espace après une virgule, jamais auparavant, tout comme en anglais régulier.
# Good x[, 1]
Bad
x[,1]
x[ ,1]
x[ , 1]
Parenthèses
Ne placez pas d’espaces à l’intérieur ou à l’extérieur des parenthèses pour les appels de fonctions réguliers.
# Good mean(x, na.rm = TRUE)
# Bad mean (x, na.rm = TRUE) mean( x, na.rm = TRUE )
espace avec function if
Placez un espace avant et après lorsqu’il est utilisé avec , ou .()ifforwhile
# Good
if (debug) {
show(x)
}
# Bad
if(debug){
show(x)
}
espace et fonction
Placez un espace après utilisation pour les arguments de fonction :()
# Good
function(x) {}
# Bad
function (x) {}
function(x){}
Embrasser
L’opérateur embrassant, , doit toujours avoir des espaces intérieurs pour aider à souligner son comportement particulier:{{ }}
# Good
max_by %
group_by({{ by }}) %>%
summarise(maximum = max({{ var }}, na.rm = TRUE))
}
# Bad
max_by %
group_by({{by}}) %>%
summarise(maximum = max({{var}}, na.rm = TRUE))
}
Blocs de code
Accolades bouclées, , définir la hiérarchie la plus importante du code R. Pour faciliter la vue de cette hiérarchie :{}
{ devrait être le dernier caractère sur la ligne. Le code connexe (par exemple, une clause, une déclaration de fonction, une virgule de fuite, …) doit être sur la même ligne que l’accolade d’ouverture.if
Le contenu doit être indenté par deux espaces.
} devrait être le premier caractère sur la ligne.
Blocs de code exemple bon
# Good
if (y < 0 && debug) {
message("y is negative")
}
if (y == 0) {
if (x > 0) {
log(x)
} else {
message("x is negative or zero")
}
} else {
y^x
}
test_that(“call1 returns an ordered factor”, {
expect_s3_class(call1(x, y), c(“factor”, “ordered”))
})
tryCatch(
{
x
Blocs de code exemple mauvais
# Bad
if (y < 0 && debug) {
message("Y is negative")
}
if (y == 0)
{
if (x > 0) {
log(x)
} else {
message("x is negative or zero")
}
} else { y ^ x }
Déclarations en ligne
Il est correct de laisser tomber les accolades bouclées pour des déclarations très simples qui s’adaptent sur une ligne, tant qu’ils n’ont pas d’effets secondaires.
# Good y
Les appels de fonction qui affectent le flux de contrôle (comme return(), stop()ou continue) doivent toujours aller dans leur propre {}bloc:
# Good
if (y < 0) {
stop("Y is negative")
}
find_abs 0) {
return(x)
}
x * -1
}
# Bad
if (y < 0) stop("Y is negative")
if (y < 0)
stop(“Y is negative”)
find_abs 0) return(x)
x * -1
}
Coercition de type implicite
Évitez la contrainte de type implicite (par exemple de numérique à logique) dans les ifinstructions:
# Good
if (length(x) > 0) {
# do something
}
# Bad
if (length(x)) {
# do something
}
Instructions de commutation
Évitez les switch()déclarations basées sur la position (c’est-à-dire préférez les noms).
Chaque élément doit aller sur sa propre ligne.
Les éléments qui passent par l’élément suivant doivent avoir un espace après =.
Fournissez une erreur de transition, sauf si vous avez préalablement validé l’entrée.
# Good
switch(x
a = ,
b = 1,
c = 2,
stop(“Unknown x”, call. = FALSE)
)
# Bad switch(x, a = , b = 1, c = 2) switch(x, a =, b = 1, c = 2) switch(y, 1, 2, 3)
Longues lignes
# Good do_something_very_complicated( something = "that", requires = many, arguments = "some of which may be long" )
# Bad
do_something_very_complicated("that", requires, many, arguments,
"some of which may be long"
)
# Good paste0( "Requirement: ", requires, "\n", "Result: ", result, "\n" )
# Bad paste0( "Requirement: ", requires, "\n", "Result: ", result, "\n")
Cession
Utilisez
