プログラムと美しさ：第四章　命名　―東京ディズニーはご法度？―

　プログラミングの本質は命名と分類である。そして分類の本質は命名である。と言っても過言でないほど、命名は重要な行為である。プログラマは膨大な数のデータや操作を、名前をつけることによって分類、識別する。適切な名前をつけることで利便性が増すことは、パソコンのファイル管理からもおわかりいただけるだろう。

　名前のないものは管理できない（管理されたくないものには名前をつけないことである）。だからプログラムではあらゆるものに名前をつける。ただつければいいというわけではない。名前が実体と一致していないと、正しく利用するのに支障が出てしまう。二十四時間開いている「セブン・イレブン」や千葉県浦安市にある「東京ディズニーランド」は、プログラムの世界ではご法度である。誤解を生んでしまう。

　美しい名前は、わかりやすく、実体に即している。対象を一意に特定できる情報を持ち、かつ、長すぎない。中に収められているのが何なのか、素早く判断できるように命名されている。

　美しい名前は、また、期待を裏切らない。二郎の兄は一郎だし、トメさんに下の子はいない。期待を裏切るコードに出会うと、つい小さく「騙された」とつぶやいてしまうものだが、何も騙そうとしたわけではあるまい。紆余曲折を経て、当初の目論見と中身が変わってしまったのだろう。ならばちょっとした手間である、名前も変えておこう。

　ネーミングセンスという言葉が広く使われるように、命名にはセンスが表れる。特徴を捉えて言語化するのがうまい、というのがその正体だろう。ただし、特徴を捉えるところまでは共通だが、それをどんな塩梅で言語化するかは、目的によって大きく異なる。

　権力者の風刺が目的なら、あだ名には皮肉とユーモアのバランスが求められる。皮肉が過ぎれば消されてしまうかもしれない。商品名のように目を引くことが主要な目的なら、共感とインパクトが重要な要素になるだろう。その際、特徴はわかりやすくデフォルメされることが多い。

　プログラムにおける命名は少し事情が異なる。初見の人に訴えかけることが目的ではないので、インパクトはそれほど重要ではない。ユーモアに至っては全く必要がない。趣向に富んだ命名を見かけることがたまにあるが、プログラムの世界では逆に美しさを損なってしまう。遊び心は無用である。また、特徴を捉えるのは重要だが、求められるのは感覚的な鋭さよりも統計的な妥当性だろう。そして言語化にあたって心がけるべきは、一部の強調でなく、全体の要約である。

　プログラムにおける命名の主たる目的は識別である。識別するためには、プログラム内での役割や、出現する文脈を意識することも大切となる。プログラムを構成する要素に、それ単体の絶対的価値はない。ほかの要素との関連において、初めて価値が生まれるのである。したがって、単体で見てふさわしい名前がつけられているというだけでは十分でない。属する領域（スコープ）の中で役割が明確になってこその命名である。

　実生活でたとえるなら、「燃えるごみ」「燃えないごみ」…といった分別ごみの表記をイメージしていただくとよい。分類自体は処理事情に依存するとして、誰目線でどこの差異に着目して簡潔に命名するか。センスの見せ所である。何をどこに捨てればよいか、ぱっと見でわかるように名前分けした自治体の担当者は、一つプログラマの適性があると言えよう。

　あるいは、サポート窓口でよくある自動音声応答システムの選択肢にも同様のセンスが表れる。わかりやすい番号分けは、トラブルに巻き込まれた（と少なくとも思っている）人の怒りを鎮めるのに役立つはずだ。わざと迷わすようなひどい番号分けもあるが、そこで怒りを増幅させていることに早く気づこう。

　統一性も忘れてはならない。整合性のとれた、統一された基準に基づいた命名は、コードの素早い理解の助けとなる。形式的な統一性を保つための方策として、開発プロジェクトでは命名規約を設けるのが一般的である。一人や少人数のチームでは緩く暗黙的な場合もあるが、規模の大きい開発ではきちんと文書化されることが多い。そこには「動詞で始める」「名詞で終わる」「小文字で始める」といったルールが、それぞれコードを構成する要素の種類ごとに網羅的に定められている。採用するプログラミング言語に標準的な規約があるなら、基本的なルールはそこに委ねてしまうことも少なくない。プログラミングにおいて、より大きな標準があればそれに倣うというのは、特にオープンな共同開発が進んだ現代の、一般的な推奨事項である。法令にたとえて言うなら、憲法にないものを法律、法律にないものを条例で定めればよい。

　規約はかなりの分量になることもある。すべてを頭に入れるのはたいへんだし、いちいち規約に照らしていては開発効率が落ちる。人間だから忘れることもあるだろう。最近では、自動的にチェックを行い、ルール違反を警告してくれるツールも普及しているので、これを活用しない手はない。より効率的に規約の遵守を徹底し、プログラマが生産性の高い作業に集中するため、この辺りはさらなる進化が期待される分野でもある。

　規約を設けるのは単に整頓するためではない。ルールは名前を補完する。それが何であるかの形式的な基礎情報を与え、コードの可読性を高める。見た目の章で述べたように、「ぱっと見でわかる」と「よく見ればわかる」は全然違うことである。ぱっと見でわかるコードは美しい。美しいコードは、むやみに文脈を追うことを強いない。

　規約が意味づけの一端も担い、それらが遵守されるなら、その意味をプログラマ間だけでなく、動作主たるコンピュータと共有してもいいだろう。そうした発想から、規約が明示的な指定に代わってコンピュータの動作を規定する仕組みが提供されることもある。実装を簡素にできることが特徴で、ポピュラーな設計理念としての地位を確立している。

　命名規約の付録として、使用する単語の統一を図るべく、用語辞書が作られることもある。頻出する業務用語など、個々のプログラマのセンスに委ねてしまうと収拾しがたい混乱が生じてしまうため、それを防ぐのが目的である。

　たとえば車に関するシステムを開発するとして、「車」をある人は car、別の人は vehicle、また別の人は automobile などまちまちに書いていたのでは、コードがわかりづらくなる。後から参加するプログラマもどれに従えばよいか迷ってしまうだろう。政治的視点から一番発言力のありそうな人に従うべきか、統計的視点から出現回数の最も多いものにするか、創造的感性が触発されて kuruma を新たにエントリするか。ひどいケースだと、Ａさんが書いた car をＢさんが vehicle に書き換え、その後Ａさんが car に戻すなど、不毛な争いが繰り広げられることもある。相手に恨みがあるわけではない。自らの信じるところに従い、それを徹底したまでである。しかし益は薄い。コンピュータはどちらでも同じように動くのだ。プログラムの状態も人間関係も、これでは美しいとは言えない。

　あらかじめ「車は car で表す」と決めておけば、このような事態を避けることができる。統一化された美しい命名は、開発の無駄を省き、コードを通したプログラマ間のコミュニケーションも円滑にしてくれるだろう。

　本章冒頭の「分類の本質は命名である」については、別に詳しく書く機会があるかもしれない。ここでは、フォルダとファイル名をすべてつなげると「完全パス」という一つの名前になることを例示するにとどめよう。

序章
第一章　その美の特徴
第二章　見た目と冗長性
第三章　ロジック
第四章　命名
第五章　アーキテクチャ
第六章　リファクタリング
第七章　デザインパターン
第八章　正規化
終章