「読みやすさ」には静的な型よりも名前のほうが重要

『名前重要』というのは Ruby でよく言われるけど、これは Ruby に限らずどのプログラミング言語でもいえること。ただ、スクリプト言語では変数の型がないので、Java や C に比べてより名前が重要になってくる。

たとえば、次のような Ruby プログラムがあったとする。このコードから、メソッドの引数に何を渡せばいいか、想像してほしい。

def compile(file)
  ....
end

これは実際に自分が直面した例であり、このときはファイル名かまたは File オブジェクトだと思った。最初にファイル名を渡してみたがうまく動作しない。じゃあ、ということで File オブジェクトを渡したが、これもうまく動かない。

ret = compile('file.txt')            # 動かず
ret = compile(File.new('file.txt'))  # これも動かず

これには困った。「file」という引数名から想像できるのは、ファイル名か File オブジェクトくらいしか思いつかなかったからだ。残念ながらろくにドキュメントを書いているようなソースではなかったので、諦めて compile() の定義を読み出した。

そこでようやく分かったのだが、「file」という引数は、ファイル名でも File オブジェクトでもなく、ファイルの中身 (つまり File.read('file.txt') の結果) を表すということだ。え〜っ、ファイルの中身を表す引数の名前が「file」!? そりゃわからんて。ここは「file_content」か、どうせ文字列なら何でも受け取るんだから「str」でよくね? 「file」という名前じゃ混乱するだけやで。

これだから動的言語は・・・と思う人もいるだろうが、実はこの問題は静的な型でも解決できない。たとえば次のような Java コードを見ればわかる。「file」が文字列であることはわかるが、それがファイル名なのかファイルの中身なのかは、これだけでは判断できないのだ*1。

String compile(String file) {
  ....
}

結局、「型」というのはあくまで「型」を表すだけであって、「意図」や「中身」を表すわけではないということだ。もしそれらを「型」で表そうとすると、文字列型とは別に「ファイル名を表す型」と「ファイルの中身を表す型」の両方を用意しないといけない。それはそれでおもしろい研究材料にはなると思うが、実際には型を定義する手間が多すぎて使いづらくなるだろう。

じゃあやっぱり静的な型なんかあっても意味ないじゃん、というスクリプト言語バカがいたら困るので言っておくけど、ここでの趣旨は「型ですべてを解決できるわけではない」ということであって、静的な型を否定するものではない。実際、readability という観点からは、ソースにより多くの手がかりを与えてくれる「型」の存在は大きい。ただ、それですべてが解決できるわけではないという、ごくごく当たり前のことをいっているだけ。趣旨を勘違いしないよう注意してほしい。

話をもとに戻すと、先のプログラムでは「String file」と指定されてあったが、「String」という型が指定されることよりも、引数の名前を「file」から「file_content」に変更するほうが readability は上がる。もちろん型を使うとコンパイルチェックがかかるという大変大きなメリットがあり、名前のほうではそんなチェックはできないわけだけど*2、少なくとも readability に関する限りは型よりも名前のほうが重要だと思う。

*1:まあ Java はスクリプト言語よりも document をきちんと書く習慣が広まっているので、たいがいの場合において「file はファイルの中身ですよ」と document に書かれてあるだろう。ただ「document を書けばわかる」というのはスクリプト言語でも同じことなので、ここでは document がなかった場合を考える。

*2:もしかしたら名前でチェックできる言語もあるかもしれない。別にそういう研究があってもおかしくないし、そういう研究を否定するつもりはない。ここでは Java ではそういうチェックができないといっているだけ。趣旨を勘違いした反論もどきはやめていただくよう重ねてお願いする。