はじめに

本記事は、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 週間後の自分には、何をやろうとしていたのか理解できないことに気がつくはずです。

コメント

コメントがないと、コードを追って理解できるかはその人次第ということになりますがこれは簡単なことではありません。なぜならその人は自分とは違う方法で、自分と同じ内容をコーディングしているかもしれないからです。そこでドキュメントの作成が重要になります。

自分のコードが何をしているのか、
なぜ、何のために作られたのか、
どんな制約があるのか

などを詳細に説明します。

スケーラビリティ（拡張性）

スケーラビリティ（拡張性）を担保しダイナミックにコードを構築することです。スケーラビリティのある構築というのはそのコードが将来的に他の誰かに使われる可能性があるかどうか、ということで、もし使われるのであれば、コードに拡張性を持たせ、スケーラブルに使えるようにすることが重要、ということです。

つまり、操作するデータのサイズが大きくなってもコードが処理落ちしないよう効率的に実行し、小さなデータのロードだけでなく大きなデータのロードも処理できるようにしておく、と覚えておきましょう。

もうひとつは、コードをダイナミック、つまり動的にすることです。これは、変更する必要のない値をコード内に無理に記述しないことを意味します。