はじめに
本記事は、Googleデータアナリティクスのプロフェッショナル認定証のプログラムより、参照させて頂いています。興味を持った方は、是非受講してみてください。
R言語のコードを読みやすくする
R コード（または他のプログラミング言語）を書くときは、エラーのない、明確で一貫性のあるスタイルを用いることが重要です。そうすることで、コードが読みやすく、理解しやすくなります。
スタイル
明確で一貫性のあるコーディング スタイルを使うと、誰から見ても読みやすいコードを書くことができます。すべての R ユーザーに義務づけられた公式のコーディング スタイル ガイドはありません。しかし、長年にわたり R ユーザーのコミュニティでは、共有の慣習や好みに基づいてコーディング スタイルが開発されてきました。
一貫したコーディング スタイルを使用する 2 つ の理由
- チームなどで共同作業をする際に、誰もが簡単にお互いのコードを読んだり、共有、編集したり作業したりできる。
- 一人で作業している場合、後でコードを見返してエラーを修正、変更する際の効率が上がる。
命名
ファイル
- ファイル名は意味のあるものにし、末尾は .R にする。
- ファイル名に特殊文字を使用することは避け、数字、文字、ダッシュ、アンダースコアに統一する。
# Good
explore_penguins.R
annual_sales.R
# Bad
Untitled.r
stuff.r
オブジェクト名
- 変数名と関数名は小文字にする。
- オブジェクト内の単語を区切るには、アンダースコア「 _ 」を使用し、明確で簡潔、かつ意味のある名前を付けるようにする。
- 一般的に、変数名は名詞にする。
# Good
day_one
# Bad
DayOne
- 関数名は動詞にする。
# Good
add ()
# Bad
addition ()
構文
空白（スペース）を入れる
- 演算子 (== , + , -, <-, etc.) は空白で囲む。
# Good
x == y
a <- 3 * 2
# Bad
x==y
a<-3*2
- 必ずカンマの前でなく後ろに空白を入れる。
# Good
y[, 2]
# Bad
y[,2]
y[ ,2]
- 括弧や角括弧の中のコードにはスペースを入れないようにする（カンマがある場合は上記を参照）。
# Good
if (debug) do(x)
species[“dolphin”, ]
# Bad
if ( debug ) do(x)
species[ “dolphin” ,]
- 関数以外の左括弧の前にはスペースを入れ、関数の場合にはスペースを入れない。
# Good
sum(1:5)
plot(x, y)
# Bad
sum (1:5)
plot (x, y)
波括弧
- はじめの中括弧は、必ず行に単独で記述せず常に改行し、終わりの中括弧は（else 文が続く場合を除き）常に単独で記述する。波括弧の中のコードは、必ずインデントする。
# Good
x <-7
if (x > 0) {
print("x is a positive number")
} else {
print ("x is either a negative number or zero")
}
# Bad
x <-7
if (x > 0)
{
print("x is a positive number")
}
else {
print ("x is either a negative number or zero")
}
インデント
- コードをインデントする場合は、半角スペースを使用する。タブを使ったり、タブとスペースが混在したりしないようにする。
行の長さ
- コードは 1 行 80 文字以内に収まるようにし、適切な大きさのフォントで印刷されたページにうまく収まるようにする。
- ほとんどのスタイルガイドでは、1 行が80 文字（または 120 文字）以上を超えないようにとされている。RStudio でマージンを設定する場合は、Tools → Global Options → Code → Display で、Show margin のチェックボックスにチェックを入れ、margin column を 80 (または 120 )にすることで適切な行の長さを保つことができる。
代入
- 代入には = ではなく <- を使用する。
# Good
z <- 4
# Bad
z = 4
共同作業
コメント
- コメント行全体は、コメント記号と半角スペース（# ）で始める。
# Good
# Load data
# Bad
Loaddata
リソース
- R コードを書く（ tidyverse で作業する）際の重要なスタイル、ルールに関する概要への理解を深めるには、 tidyverse style guide をチェックしましょう。
修正
R でコードのデバッグをする際は、
- まず起きている問題を正しく見極めることから始めます。問題を見極めるための最初のステップは、自分が「コードがどう動作するのを期待していたのか」を理解することです。
- 次に、実際にコードがどう動作したのか、そしてそれが予想とどう違ったのかを見極めましょう。
たとえば、glimpse() 関数を実行して、penguins というデータセットの概要を表示するため、以下のようなコードを書いたとします
Glimpse(penguins)
Error in Glimpse(penguins) : could not find function "Glimpse"
（Glimpse(penguins) でエラー: 関数 "Glimpse" を見つけることができませんでした）
このようなエラーメッセージが表示されました。ここでの問題は、Glimpse を小文字の "g" で書くべきところを、大文字の "G" から書き始めてしまっていることです。glimpse(penguins) というコードを実行すれば、期待通りの結果が得られます。
問題を見極める際、以下のような問いかけをすると、ご自身やチームメンバーが問題を発見できる可能性が高くなります。
- 何と入力したか？
- 何を期待していたか？
- 得られた結果はどんなものだったか？
- その結果は、最初に期待していたものとどう違うか？
- そもそも期待していたことは正しかったのか？
バグの中には、発見が難しく、原因を突き止めるのが困難なものもあります。エラーメッセージに遭遇したときや、バグについて手助けが必要なときは、まずはそのバグに関する情報をネットで検索してみましょう。実はよくあるエラーで、すぐに解決できるかもしれません。
コーディングのヒント
構成
スクリプトを書く時やコーディングの際に 重要なことは、全体的に読みやすいように 構成することです。 多くの場合、皆さんは チームで仕事をすることになります。 自分がその仕組みを理解するだけでなく 一緒に仕事をする他の誰かが そのスクリプトで やろうとしていることを 理解できるような状態に しておくことです。 またスクリプトは 効率的に動作するだけでなく 冗長、複雑になりすぎないことも 非常に重要なポイントです。
読みやすさの観点から重要なのは 自分のコードを見た時 同じことを何度も書いていたり 同じロジックやアルゴリズムを 何度も使っていると気づいたりした場合 その時点でコードを統合し より簡潔なものへと修正するのです。 それによってコードが 読みやすくなるだけでなく 他の人が読む助けにもなります。 2 週間後にそのコードを見た 自分を助けることにもなります。 コーディングを始めると、 今理解できていることが 3 週間後の自分には、 何をやろうとしていたのか 理解できないことに気がつくはずです。
コメント
コメントがないと、 コードを追って理解できるかは その人次第ということになりますが これは簡単なことではありません。 なぜなら その人は自分とは違う方法で、 自分と同じ内容を コーディングしているかもしれないからです。 そこでドキュメントの作成が 重要になります。
- 自分のコードが 何をしているのか、
- なぜ、何のために作られたのか、
- どんな制約があるのか
などを 詳細に説明します。
スケーラビリティ（拡張性）
スケーラビリティ（拡張性）を担保し ダイナミックにコードを構築することです。 スケーラビリティのある構築というのは そのコードが将来的に 他の誰かに使われる可能性があるかどうか、 ということで、 もし使われるのであれば、 コードに拡張性を持たせ、 スケーラブルに使えるようにする ことが重要、ということです。
つまり、 操作するデータのサイズが大きくなっても コードが処理落ちしないよう 効率的に実行し、 小さなデータのロードだけでなく 大きなデータのロードも処理できるように しておく、と覚えておきましょう。
もうひとつは、コードをダイナミック、 つまり動的にすることです。 これは、変更する必要のない値を コード内に無理に記述しないことを 意味します。