Rubyで変数宣言っぽいものをした方が読みやすくなるとき

RubyはCのように変数宣言のための特別な構文はなく、変数に代入する式を書くとそれ以降その変数を使えるようになります。

1 + 1             # <- ここでは「message」変数を使えない
message = "Hello" # <- ここから「message」変数を使える
puts(message)     # <- ここでは「message」変数を使える

そのため、明示的に変数を宣言しようとすることはほとんどありません。そのように書かれているRubyのコードを見ると違和感を覚えるほどです。何か特別な意図があるのではないかと考えてしまいます。

message = nil # <- 変数を宣言するための代入式

1 + 1
message = "Hello"
puts(message)

しかし、このように変数を宣言するために代入式を使った方が読みやすくなる場合があります。どういう場合かを例と理由をつけて説明します。なお、どうしてこのようなことを書く気になったのかというと、コミットへのコメントサービスを実施したときのコメントのやりとりで話題になり、「こういう考えでやっている」ということを説明したからです¹。

なお、スコープを広げるためには変数宣言をする「必要」がありますが、今回は、どういうときに必要かという話はしません。こういうときに使うのが「オススメ」という話だけします。

デフォルト値を設定するケース

「オススメ」のケースはデフォルト値を設定するケースです。このケースでは変数宣言のように最初に変数を初期化する必要はありません。しかし、次のように初期化した方が読みやすくなります。これは、一見、変数宣言のように見えますが、そうではなく、単にnilを設定しているだけです。

variable = nil
# ...variableを設定するかもしれない処理...
variable ||= default_value
variable

この書き方をしない場合はifを使って書いたりします。

if condition1
  variable = get_value1
elsif condition2
  variable = get_value2
else
  variable = default_value
end

単純な場合はこれでもよいのですが、次のように値を取得しようとしても失敗するかもしれない、という場合はデフォルト値の設定箇所が複数になります。

if condition1
  variable = get_value_if_success
  p variable # => nilかもしれない
  if variable.nil?
    variable = default_value # デフォルト値の設定箇所1
  end
elsif condition2
  variable = get_value_from_network
  p variable # => nilかもしれない
  if variable.nil?
    variable = default_value # デフォルト値の設定箇所2
  end
else
  variable = default_value # デフォルト値の設定箇所3
end

こうなると複雑なので次のような形にする方がオススメです。

variable = nil
if condition1
  variable = get_value_if_success
elsif condition2
  variable = get_value_from_network
end
variable ||= default_value # デフォルト値の設定
variable

この形では「デフォルト値の設定」という処理を1回だけ書けば済むようになっているのがよいところです。また、その処理をifの中ではなく必ず通るところに書いているおかげで「あぁ、この処理の塊では必ずデフォルト値を設定するんだな」感がでるのもよいところです。

ifでがんばる場合だと「抜けはないよね？抜けがあったとしたらそれは意図的なもので問題ないんだよね？」というのが気になります。

まとめ

変数宣言をする必要のないRubyでも、変数宣言っぽいことをした方が読みやすくなるケースがあります。それは「デフォルト値を設定するケース」です。

ちょっとしたことでも、読みやすくしたり、意図を伝えやすく書けたりするものです。この話を書くきっかけになったのは、Rubyをよく知らない人がRubyのコードのコミットを見て「Rubyはよく知らないんだけど、変数宣言はいらないのに変数宣言っぽいことをしているのはなんで？」とコメントしたことでした。このような何気ない疑問からちょっとした工夫が明文化され、開発チームの資産になったりします。

間違ったところを指摘するためだけに他の人のコードをチェックするのではなく、コミットを見て、気になったことを気軽にコメントできる文化を作ってみてはいかがでしょうか。今まで気づいていなかった自分たちのよいところに気づけるかもしれませんよ。

参考:

リーダブルコードの解説：「よいコードを書くことが当たり前」にしようよ、（中略）、そのためにはみんながみんなのコードを読む文化になっていないとね、（中略）、みたいな話
コミットへのコメントサービス：「みんながみんなのコードを読む文化」を作ることを支援するサービス²

今、そのコメントを見なおしてみると、このやりとりは2013/5/13にあったので、書こう思い立ってから半年も経っていたのですね。。。 ↩
コミットへコメントすることがメインではないので、もっとよいしっくりくるサービス名がありそうだけど。。。 ↩

ククログ

デフォルト値を設定するケース

まとめ

関連情報