Quel est votre style préféré de nommage des variables dans R?

Dont les conventions de nommage des variables et des fonctions etes-vous en faveur de la R du code?

Aussi loin que je peux dire, il y a différentes conventions qui coexistent dans cacophonique harmonie:

1. L'utilisation de la période de séparateur, par exemple 

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

Pour: A des précédents historiques dans le R de la communauté, répandue dans toute la R de base, et recommandé par Google R Guide de Style.

Contre: Rife avec un orientée objet, les connotations, et source de confusion pour R les débutants

2. L'utilisation de souligne 

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

Pour: d'Une convention commune dans beaucoup de programmation langs; favorisée par Hadley Wickham du Guide de Style, et utilisé dans ggplot2 et plyr paquets.

Contre: Pas historiquement utilisé par les programmeurs R; est fâcheusement lié à '<-' opérateur en Emacs-Parle-Statistiques (modifiables avec "ess-bascule-underscore').

3. L'utilisation de mélanges de capitalisation (camelCase)

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

Pour: Semble avoir une large adoption dans plusieurs communautés de langue.

Contre: A précédent dans l'histoire récente, mais pas toujours utilisé (dans une autre R de base ou de sa documentation).

Enfin, comme si ce n'était pas assez déroutant, je me dois de souligner que le Google Guide de Style plaide pour la notation de point pour les variables, mais mixtes de capitalisation pour les fonctions.

Le manque de cohérence de style à travers les packages R est problématique à plusieurs niveaux. À partir d'un point de vue développeur, il rend le maintien et l'extension des autres code difficile (esp. où son style est incompatible avec votre propre). À partir d'un R point de vue utilisateur, le manque d'uniformité dans la syntaxe se R de la courbe d'apprentissage, en multipliant les moyens d'un concept peut être exprimé (p. ex. est-ce que la date de coulée fonction asDate(), comme.date(), ou as_date()? Non, c'est comme.Date()).

  • Il existe également des cas de MATLAB style alllowercase les noms de variables, et beaucoup de droite de l'équation noms très courts (x, y, etc.).
  • des traits de soulignement sont comme le python, j'ai donc tendance à utiliser des traits de soulignement. L'ESS doit être fixe, c'est vraiment idiot.
  • Il n'y a rien à corriger, il a une option pour ça. Mais le comportement par défaut est d'interpréter un trait de soulignement comme un raccourci pour <- vous permet d'économiser à la presse. Donc, si vous publiez des variables avec des traits de soulignement (Hi, Hadley) vous force à chaque ESS utilisateur à appuyer sur _ deux fois pour obtenir l'original bahaviour -- ou ont personnalisé leur ESS de l'installation. Je préfère encore camelCase par une nouvelle milles marins.
  • Concernant l'ESS et Emacs, vous pouvez désactiver ce comportement gênant en mettant ess-toggle-underscore nil) dans votre .emacs fichier. Espérons que cette aide.
  • camelCase a des problèmes aussi, par exemple, la norme de chameau Cas ImfDataTransformed ou le naturel de la version étendue IMFDataTransformed ne sont pas aussi facile à lire que mon préféré TOGGLEcamelCase: IMFdataTransformed...
  • Je vais voter pour fermer cette question hors-sujet parce que les réponses sont forcément opinion.
  • Comme un cas particulier, puisque caractère souligné (_) ne peut pas être utilisé dans la première lettre, la seule façon possible d'indiquer une variable interne est de placer un point (.) avant le nom (comme _name, ou __name en C/C++). Par exemple .name. Notez que les numéros ne pouvait pas être la deuxième lettre après un point (.) selon Faire un point de vue Syntaxique des Noms Valides. Reportez-vous à stackoverflow.com/a/38448219/2101864 pour les variables internes.

InformationsquelleAutor medriscoll | 2009-12-22
  1. 79

    Bonne réponse à la question précédente, donc juste un peu pour ajouter ici:

    • des traits de soulignement sont vraiment gênant pour l'ESS utilisateurs; étant donné que l'ESS est assez largement utilisé, vous ne verrez pas beaucoup de traits de soulignement dans le code écrit par l'ESS utilisateurs (et que l'ensemble comprend un tas de R de Base ainsi que CRAN auteurs, excptions comme Hadley nonobstant);

    • points sont mal trop, car ils peuvent être mélangées dans la méthode simple pour l'expédition, et, je crois, j'ai lu des commentaires à cet effet, sur l'une de la R de la liste des points, un artefact historique et n'est plus encouragée;

    • donc, nous avons un gagnant clair, encore debout dans le dernier tour: camelCase. Je suis également pas sûr si j'ai vraiment d'accord avec l'assertion de 'manque de precendent dans le R de la communauté'.

    Et oui: le pragmatisme et la cohérence trump dogme. Donc ce qui fonctionne et est utilisé par des collègues et des co-auteurs. Après tout, nous avons encore des blancs et des accolades pour argumenter sur l' 🙂

    • +1 Bien dit! [Si seulement le noyau de l'équipe serait de mettre définitivement un guide de style; je crois que cela permettrait de donner plus de crédibilité à leur déjà implicite d'utilisation.]
    • Je pourrais juste être misremembering basé sur mon propre biais en faveur des cas mixtes, mais je crois que c'est ce que RG toujours utilisé lorsque je travaillais pour lui. Je me figure ce qui est bon pour RG est bon pour moi!
    • Geoff: Pas une mauvaise règle pour aller par la 🙂
    • Dirk - je suis en train de donner votre réponse les pouces jusqu'ici, mais il serait merveilleux si ce style de préférence ont été réifiée dans un document quelque part à r-project.org. À l'heure actuelle, il est flottant dans l'onu-Google-mesure de la conscience collective de la R Core Team :).
    • Merci pour thumbs-up. Comme pour la pour la "canonique document": souhaitant le long de ne pas faire en sorte, ou je serais d'équitation poneys rose. Peut-être vous pouvez commencer par la création de quelque chose, que vous pouvez coller sur les R Wiki et nous avons tous de modifier, d'adopter et d'y adhérer. L'espoir est éternel, comme ils disent...
    • Je n'ai pas de problèmes avec camelCase bien que je préfère les traits de soulignement et ne pas utiliser de l'ESS. Je dirai qu'il serait bien d'avoir plusieurs conventions de nommage pour les différentes situations comme le google guide vise à camelcase pour les fonctions. Il augmente considérablement la compréhension. Depuis des traits de soulignement sont utilisés dans un certain nombre de langues, l'idéal serait d'avoir pour une chose, que ce soit des variables, des fonctions et al
    • J'ai l'intention de commencer à se diriger vers chameau boîtier basé sur votre recommandation, mais je suis curieux de savoir si vous savez pourquoi ?make.names semble suggérer que la dot noms séparés sont privilégiées?
    • Désolé, David, mais j'ai écrit mal ci-dessus dans ma réponse. Comme je l'ai écrit, je préfère de beaucoup camelCase plus de point.noms séparés.
    • Mettre (ess-toggle-underscore nil) dans votre .emacs permet de résoudre le problème.
    • Je n'utilise pas l'ESS, mais j'écris beaucoup de fonctions R avec des traits de soulignement. Pourquoi sont souligne incommode pour l'ESS utilisateurs? Existe-il des solutions de contournement?

    InformationsquelleAutor Dirk Eddelbuettel
  2. 70

    J'ai fait un sondage sur ce que les conventions de nommage qui sont effectivement utilisés sur CRAN qui a été accepté à la R Journal 🙂 Voici un graphique résumant les résultats:

    Quel est votre style préféré de nommage des variables dans R?

    S'avère (pas de surprises, peut-être) que lowerCamelCase a été le plus souvent utilisé pour les noms de fonction et de la période.noms séparés le plus souvent utilisé pour les paramètres. Pour utiliser UpperCamelCase, tel que préconisé par Google R guide de style est vraiment rare, et il est un peu étrange qu'ils préconisent à l'aide de cette convention.

    L'article complet est ici:

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

    • Comment se fait-les pourcentages ne s'additionnent à 100%?
    • Parce qu'un nom peut correspondre à beaucoup de naming convetions. print correspond à toutes les conventions, sauf UpperCamel et .OTHER_style.
    InformationsquelleAutor Rasmus Bååth
  3. 32

    Souligne tout le chemin! Contrairement à l'opinion populaire, il y a un certain nombre de fonctions de base R que l'utilisation des caractères de soulignement. Exécuter grep("^[^\\.]*$", apropos("_"), value = T) de les voir tous.

    Je utiliser la langue officielle Hadley style de codage 😉

    • Ce qui est propre! Je n'étais pas au courant de la à propos fonction avant. Ceci renvoie à 10 fonctions pour moi dans la R 2.9.0; j'ai peine à le dire que c'est une raison impérieuse. Quel est votre justification pour souligne quand ils sont clairement en minorité pour R?
    • Eh bien, c'est 16 dans la R 2.10.0, donc c'est une augmentation de 60% par version 😉 en fait je les aime parce qu'ils me rappellent de Ruby; camelCase me rappelle de Java.
    • Hadley, mon coeur dit à l'appui de votre trait de soulignement de l'insurrection, mais ma tête, dit-respect de la norme communautaire, et de dire oui à camelCase. 🙁 Mais peut-être auto-consistance est tout ce qui compte.
    InformationsquelleAutor hadley
  4. 4

    J'aime camelCase lorsque le chameau apporte réellement quelque chose de significatif, comme un type de données.

    dfProfitLoss, où df = dataframe

    ou

    vdfMergedFiles(), où la fonction prend la forme d'un vecteur et crache un dataframe

    Pendant que j'y pense _ ajoute vraiment à la lisibilité, il semble juste être trop de problèmes avec l'aide d' .-_ ou d'autres caractères dans les noms. Surtout si vous travailler dans plusieurs langues.

    InformationsquelleAutor Robert
  5. 3

    Ça se résume à la préférence personnelle, mais je suis le google guide de style parce que c'est cohérent avec le style de l'équipe de base. Je n'ai pas encore de voir un trait de soulignement dans une variable dans la base de R.

    InformationsquelleAutor Shane
  6. 3

    Comme je l'ai souligné ici:

    Comment le niveau de verbosité des identificateurs d'affecter les performances d'un programmeur?

    il est important de garder à l'esprit la façon compréhensible vos noms de variable à vos collaborateurs/utilisateurs, s'ils sont non-natifs...

    Pour cette raison que je dirais des traits de soulignement et des périodes sont mieux que la capitalisation, mais comme vous le soulignez la cohérence est essentielle dans votre script.

    InformationsquelleAutor David Lawrence Miller
  7. 2

    Comme d'autres l'ont mentionné, souligne vis beaucoup de gens. Non, il n'est pas verboten mais il n'est pas particulièrement fréquentes.

    À l'aide de points comme séparateur est un peu poilu avec S3 classes et la comme.

    Dans mon expérience, il semble que beaucoup de la haute muckity fou de R préfèrent l'utilisation de camelCase, avec quelques point d'utilisation et une poignée de traits de soulignement.

    InformationsquelleAutor geoffjentry
  8. 0

    J'ai une préférence pour mixedCapitals.

    Mais j'ai souvent des périodes d'utilisation pour indiquer que la variable est de type:

    mixedCapitals.mat est une matrice.
    mixedCapitals.lm est un modèle linéaire.
    mixedCapitals.lst est un objet de la liste.

    et ainsi de suite.

    InformationsquelleAutor Jesse
  9. 0

    Habituellement je renomme mes variables à l'aide d'un ix des traits de soulignement et un mélange de capitalisation (camelCase). Des variables simples sont de nommage à l'aide de traits de soulignement, par exemple:

    PSOE_votes -> nombre de votes pour le PSOE (groupe politique de l'Espagne).

    PSOE_states -> Catégorique, indique l'état où PSOE gagne {Aragon, Andalousie, ...)

    PSOE_political_force -> Catégorielles, 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 (hde projet -> nombre de voix, les états, la position)

    Si ma variable est une suite de appliqué en fonction des deux Variables I à l'aide d'un mixte de capitalisation.

    Exemple:

    positionXstates <- xtabs(~unis+position, PSOE_07)

    InformationsquelleAutor calejero