Quel est votre style préféré pour nommer les variables dans R?
Quelles conventions pour nommer les variables et les fonctions privilégiez-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 du séparateur de période, par exemple
stock.prices <- c(12.01, 10.12)
col.names <- c('symbol','price')
Avantages: A une priorité historique dans la communauté R, répandue dans tout le noyau R, et recommandée par Guide de style R de Google .
Inconvénients: Riche de connotations orientées objet et déroutant pour les débutants R
2. Utilisation de soulignements
stock_prices <- c(12.01, 10.12)
col_names <- c('symbol','price')
Avantages: Une convention commune dans de nombreuses langues de programmation; favorisé par Hadley Wickham's Style Guide , et utilisé dans les paquets ggplot2 et plyr.
Contre: Non utilisé historiquement par les programmeurs R; est mappé de façon agaçante à l'opérateur "<-" dans Emacs-Speaks-Statistics (modifiable avec "ess-toggle-underscore").
3. Utilisation de capitalisation mixte (camelCase)
stockPrices <- c(12.01, 10.12)
colNames <- c('symbol','price')
Avantages: Semble avoir une large adoption dans plusieurs communautés linguistiques.
Contre: A un précédent récent, mais pas historiquement utilisé (dans la base R ou sa documentation).
Enfin, comme si cela n'était pas assez déroutant, je dois souligner que le Google Style Guide plaide en faveur de la notation par points pour les variables, mais de la capitalisation mixte pour les fonctions.
Le manque de style cohérent dans les packages R est problématique à plusieurs niveaux. Du point de vue du développeur, cela rend difficile la maintenance et l'extension du code des autres (en particulier lorsque son style n'est pas cohérent avec le vôtre). Du point de vue de l'utilisateur R, la syntaxe incohérente accentue la courbe d'apprentissage de R, en multipliant les manières dont un concept peut être exprimé (par exemple, cette fonction de conversion de date est-elle asDate (), as.date () ou as_date ()? Non, c'est comme. Date()).
Bonnes réponses précédentes donc juste un peu à ajouter ici:
les soulignements sont vraiment ennuyeux pour les utilisateurs ESS; étant donné que ESS est assez largement utilisé, vous ne verrez pas beaucoup de soulignements dans le code créé par les utilisateurs ESS (et cet ensemble comprend un tas de R Core ainsi que des auteurs CRAN, malgré des exceptions comme Hadley);
les points sont mauvais aussi parce qu'ils peuvent se mélanger dans une simple répartition de méthode; 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 gagnant clair toujours debout dans le dernier tour: camelCase. Je ne sais pas non plus si je suis vraiment d'accord avec l'affirmation de "manque de précendant dans la communauté R".
Et oui: le pragmatisme et la cohérence l'emportent sur le dogme. Donc, tout ce qui fonctionne et est utilisé par des collègues et co-auteurs. Après tout, nous avons encore des espaces blancs et des accolades pour discuter :)
J'ai fait une enquête sur les conventions de dénomination réellement utilisées sur CRAN qui ont été acceptées dans le Journal R :) Voici un graphique résumant les résultats:
Il s'avère (sans surprise peut-être) que lowerCamelCase était le plus souvent utilisé pour les noms de fonction et les noms séparés par des points les plus souvent utilisés pour les paramètres. Utiliser UpperCamelCase, comme le préconise le guide de style R de Google est cependant très rare, et il est un peu étrange qu'ils préconisent d'utiliser cette convention de dénomination.
L'article complet est ici:
http://journal.r-project.org/archive/2012-2/RJournal_2012-2_Baaaath.pdf
Souligne tout le chemin! Contrairement à l'opinion populaire, il existe un certain nombre de fonctions dans la base R qui utilisent des traits de soulignement. Exécutez grep("^[^\\.]*$", apropos("_"), value = T) pour les voir tous.
J'utilise l'officiel style Hadley de codage;)
J'aime camelCase lorsque le chameau fournit réellement quelque chose de significatif - comme le type de données.
dfProfitLoss, où df = dataframe
ou
vdfMergedFiles (), où la fonction prend un vecteur et crache une trame de données
Bien que je pense que _ ajoute vraiment à la lisibilité, il semble simplement qu'il y ait trop de problèmes avec l'utilisation de.-_ Ou d'autres caractères dans les noms. Surtout si vous travaillez dans plusieurs langues.
Cela se résume à des préférences personnelles, mais je suis le guide de style de Google, car il correspond au style de l'équipe principale. Je n'ai pas encore vu de soulignement dans une variable en base R.
Comme je le souligne ici:
Comment la verbosité des identifiants affecte-t-elle les performances d'un programmeur?
il convient de garder à l'esprit à quel point 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 périodes sont meilleurs que la capitalisation, mais comme vous le faites remarquer, la cohérence est essentielle dans votre script.
Comme d'autres l'ont mentionné, les soulignements vont gâcher beaucoup de gens. Non, ce n'est pas verboten mais ce n'est pas particulièrement courant non plus.
L'utilisation de points comme séparateur devient un peu velue avec les classes S3 et similaires.
D'après mon expérience, il semble que la plupart des fumiers à fort taux d'humidité de R préfèrent l'utilisation de camelCase, avec une certaine utilisation de points et une poignée de soulignements.
Habituellement, je renomme mes variables en utilisant un ix de soulignements et une capitalisation mixte (camelCase). Les variables simples sont nommées à l'aide de traits de soulignement, par exemple:
PSOE_votes -> nombre de votes pour le PSOE (groupe politique espagnol).
PSOE_states -> Catégorique, indique l'état où le PSOE gagne {Aragon, Andalousie, ...)
PSOE_political_force -> Catégoriel, indique la position entre les groupes politiques du PSOE {premier, deuxième, troisième)
PSOE_07 -> Union de PSOE_votes + PSOE_states + PSOE_political_force à 2007 (h chef -> votes, états, position )
Si ma variable est le résultat d'une fonction appliquée dans une/deux variables, j'utilise une capitalisation mixte.
Exemple:
positionXstates <- xtabs (~ états + position, PSOE_07)
J'ai une préférence pour les chapitres mixtes.
Mais j'utilise souvent des points pour indiquer le type de variable:
mixedCapitals.mat est une matrice. mixedCapitals.lm est un modèle linéaire. mixedCapitals.lst est un objet liste.
etc.