Quel est votre style préféré pour nommer les variables dans R ?

Question

Quelles conventions pour nommer les variables et les fonctions préférez-vous dans le code R ?

Pour autant que je sache, il existe plusieurs conventions différentes, qui coexistent toutes dans une harmonie cacophonique :

1. Utilisation d'un séparateur de points, par ex.

  stock.prices <- c(12.01, 10.12)
  col.names    <- c('symbol','price')

Pour : Il a un précédent historique dans la communauté R, il est répandu dans le noyau de R et il est recommandé par Guide de style R de Google .

Cons : Plein de connotations orientées objet, et déroutant pour les novices en R

2. Utilisation de caractères de soulignement

  stock_prices <- c(12.01, 10.12)
  col_names    <- c('symbol','price')

Pour : Une convention commune dans de nombreux langages de programmation ; favorisée par Guide de style de Hadley Wickham et utilisé dans les paquets ggplot2 et plyr.

Cons : N'est pas historiquement utilisé par les programmeurs R ; est fâcheusement mappé à l'opérateur '<-' dans Emacs-Speaks-Statistics (modifiable avec 'ess-toggle-underscore').

3. Utilisation de majuscules mixtes (camelCase)

  stockPrices <- c(12.01, 10.12)
  colNames    <- c('symbol','price')

Pour : Il semble avoir été largement adopté dans plusieurs communautés linguistiques.

Cons : A un précédent récent, mais n'est pas utilisé historiquement (ni dans la base R ni dans sa documentation).

Enfin, comme si cela n'était pas déjà assez déroutant, je dois signaler que le guide de style de Google préconise la notation par points pour les variables, mais la capitalisation mixte pour les fonctions.

L'absence de style cohérent entre les paquets R est problématique à plusieurs niveaux. Du point de vue du développeur, cela rend difficile la maintenance et l'extension du code d'autrui (surtout lorsque son style est incompatible avec le vôtre). Du point de vue de l'utilisateur de R, l'incohérence de la syntaxe accentue la courbe d'apprentissage de R, en multipliant les façons d'exprimer un concept (par exemple, cette fonction de coulée de date est-elle asDate(), as.date() ou as_date() ? Non, c'est as.Date()).

Answer 1

Les réponses précédentes étaient bonnes, je n'ai donc rien à ajouter ici :

• Les caractères de soulignement sont vraiment ennuyeux pour les utilisateurs de l'ESS ; étant donné que l'ESS est assez largement utilisé, vous ne verrez pas beaucoup d'underscores dans le code écrit par des utilisateurs de l'ESS (et cet ensemble comprend un grand nombre d'auteurs de R Core et de CRAN, à l'exception de Hadley) ;

• Les points sont mauvais aussi parce qu'ils peuvent être mélangés dans la distribution de méthodes simples ; je crois avoir lu une fois des commentaires à cet effet sur l'une des listes R : les points sont un artefact historique et ne sont plus encouragés ;

• Nous avons donc un vainqueur clair encore debout au dernier tour : camelCase. Je ne suis pas non plus certain d'être d'accord avec l'affirmation selon laquelle il n'y a "pas de précédent dans la communauté R".

Et oui : le pragmatisme et la cohérence l'emportent sur le dogme. Donc tout ce qui fonctionne et qui est utilisé par les collègues et les co-auteurs. Après tout, nous avons encore des espaces blancs et des accolades à débattre :)

Answer 2

J'ai fait une enquête sur les conventions de nommage qui sont réellement utilisées sur CRAN et qui ont été acceptées par le R Journal :) Voici un graphique résumant les résultats :

Il s'est avéré (sans surprise peut-être) que les minusculesCamelCase étaient le plus souvent utilisées pour les noms de fonctions et les noms séparés par des points de suspension le plus souvent utilisés pour les paramètres. Pour utiliser UpperCamelCase, comme le préconise la norme Guide de style R de Google est cependant très rare, et il est un peu étrange qu'ils préconisent l'utilisation de cette convention de dénomination.

Le document complet est ici :

http://journal.r-project.org/archive/2012-2/RJournal_2012-2_Baaaath.pdf

Answer 3

Underscores all the way ! Contrairement à l'opinion générale, il existe un certain nombre de fonctions dans R de base qui utilisent les caractères de soulignement. Exécutez grep("^[^\\.]*$", apropos("_"), value = T) pour les voir tous.

J'utilise le site officiel Le style Hadley de codage ;)

Answer 4

J'aime le camelCase quand le camel fournit réellement quelque chose de significatif -- comme le type de données.

dfProfitLoss, où df = cadre de données

o

vdfMergedFiles(), où la fonction reçoit un vecteur et renvoie un cadre de données.

Bien que je pense que le caractère _ ajoute vraiment à la lisibilité, l'utilisation de .-_ ou d'autres caractères dans les noms semble poser trop de problèmes. Surtout si vous travaillez dans plusieurs langues.

Answer 5

Comme je le souligne ici :

http://stackoverflow.com/questions/1232074/how-does-the-verbosity-of-identifiers-affect-the-performance-of-a-programmer/1239385#1239385

il est bon de garder à l'esprit la façon dont vos noms de variables sont compréhensibles pour vos collègues/utilisateurs s'ils ne sont pas des locuteurs natifs...

Pour cette raison, je dirais que les soulignements et les points sont meilleurs que les majuscules, mais comme vous le soulignez, la cohérence est essentielle dans votre script.