Rコードでは、変数と関数の命名規則はどちらが適していますか?
私が知る限り、いくつかの異なる規則があり、それらはすべて不協和音の調和で共存しています。
1。期間区切り記号の使用(例:
stock.prices <- c(12.01, 10.12)
col.names <- c('symbol','price')
長所:Rコミュニティで歴史的な優先順位があり、Rコア全体で普及しており、 GoogleのRスタイルガイド によって推奨されています。
短所:オブジェクト指向の意味合いが多く、R初心者には混乱を招く
2。アンダースコアの使用
stock_prices <- c(12.01, 10.12)
col_names <- c('symbol','price')
長所:多くのプログラミング言語で共通の慣習。 Hadley Wickham's Style Guide に好まれ、ggplot2およびplyrパッケージで使用されます。
短所:Rプログラマーによって歴史的に使用されていません。 Emacs-Speaks-Statistics( 'ess-toggle-underscore'で変更可能)の '<-'演算子に迷惑なようにマッピングされます。
3。大文字の混在(camelCase)の使用
stockPrices <- c(12.01, 10.12)
colNames <- c('symbol','price')
長所:複数の言語コミュニティで広く採用されているようです。
短所:最近の前例がありますが、歴史的には使用されていません(Rベースまたはそのドキュメントのいずれかで)。
最後に、混乱を招かないように、Googleスタイルガイドでは変数にはドット表記法を使用し、関数には大文字と小文字を混ぜて使用することを主張する必要があります。
Rパッケージ全体で一貫したスタイルがないことは、いくつかのレベルで問題があります。開発者の観点からは、他のコードの保守と拡張が困難になります(特に、スタイルが自分のコードと矛盾する場合)。 Rユーザーの観点からすると、一貫性のない構文は、概念の表現方法を乗算することにより、Rの学習曲線を急上昇させます(たとえば、日付キャスト関数asDate()、as.date()、またはas_date()ですか?いいえ、asです。日付())。
以前の良い回答なので、ここに少し追加してください:
アンダースコアは実際 ESSユーザーにとってはうっとうしい。 ESSが非常に広く使用されていることを考えると、ESSユーザーによって作成されたコードには多くの下線が表示されません(そして、このセットには、RCoreとCRAN作成者、Hadleyのような例外が含まれています);
ドットは、単純なメソッドディスパッチで混同される可能性があるため、悪です。私はかつて、Rリストの1つに対するこの効果に対するコメントを読んだと信じています。
そのため、最終ラウンドにはまだ勝者である明確な勝者がいます:camelCase。 「Rコミュニティの先駆者がいない」という主張に本当に同意するかどうかもわかりません。
そして、はい:プラグマティズムと一貫性はドグマに勝ちます。したがって、同僚や共著者によって機能し、使用されるものは何でもです。結局のところ、まだ議論する余地があります:)
私は、Rジャーナルに受け入れられたCRANで実際に使用されている命名規則について調査しました:)以下に、結果を要約したグラフを示します。
LowerCamelCaseが最も頻繁に関数名に使用され、period.separatedの名前がパラメーターに最も頻繁に使用されたことがわかります(おそらく驚くことではありません)。 GoogleのRスタイルガイド が提唱するUpperCamelCaseを使用することは非常にまれですが、その命名規則を使用することを支持するのは少し奇妙です。
完全な論文はこちらです:
http://journal.r-project.org/archive/2012-2/RJournal_2012-2_Baaaath.pdf
ずっと下線を引きます!一般的な意見に反して、ベースRにはアンダースコアを使用する関数が多数あります。それらをすべて表示するには、grep("^[^\\.]*$", apropos("_"), value = T)
を実行します。
私は公式の Hadleyスタイル コーディングを使用します;)
ラクダが実際に何か意味のあるもの、つまりデータ型を提供するとき、私はcamelCaseが好きです。
dfProfitLoss、ここでdf =データフレーム
または
vdfMergedFiles()、関数はベクトルを取り込んでデータフレームを吐き出します
_は読みやすさを本当に向上させると思いますが、名前に.-_または他の文字を使用すると問題が多すぎるようです。特に、複数の言語で作業する場合。
これは個人的な好みによるものですが、コアチームのスタイルと一貫しているため、Googleスタイルガイドに従います。ベースRの変数にアンダースコアが表示されていません。
私がここで指摘するように:
識別子の冗長性はプログラマのパフォーマンスにどのように影響しますか?
同僚/ユーザーがネイティブスピーカーでない場合、変数名がどの程度理解できるかを覚えておく必要があります...
そのため、アンダースコアとピリオドは大文字よりも優れていると思いますが、指摘するように、スクリプト内では一貫性が不可欠です。
他の人が述べたように、アンダースコアは多くの人々を台無しにします。いいえ、冗長ではありませんが、特に一般的ではありません。
区切り文字としてドットを使用すると、S3クラスなどで少し複雑になります。
私の経験では、Rのマックの多いマックの多くは、キャメルケースの使用を好むように思われます。
通常、アンダースコアと大文字の混合(camelCase)を使用して、変数の名前を変更します。単純な変数は、アンダースコアを使用して命名しています。例:
PSOE_votes-> PSOE(スペインの政治グループ)の投票数。
PSOE_states->カテゴリー、PSOEが勝つ州を示します{アラゴン、アンダルシア、...)
PSOE_political_force-> Categorial、PSOEの政治グループ間の位置を示します(最初、2番目、3番目)
PSOE_07-> PSOE_votes + PSOE_states + PSOE_political_forceの連合(2007年)(header->投票、州、位置)
変数が1つまたは2つの変数に適用された関数の結果である場合、大文字と小文字を混合して使用します。
例:
positionXstates <-xtabs(〜states + position、PSOE_07)
MixedCapitalsを好みます。
しかし、変数タイプが何であるかを示すためにピリオドをよく使用します:
mixedCapitals.matは行列です。 mixedCapitals.lmは線形モデルです。 mixedCapitals.lstはリストオブジェクトです。
等々。