# プログラミングは「名前」が9割。 _published: 2011/09/26_  　プログラミングというのは、名前をつける行為なんだと思う。 ![[6184932624_8f219b63d2_c.jpg|500]] ## プログラミングで一番大切なこと。 　もしも、プログラマーじゃない人に、「プログラミングで一番大切なことは？」と聞かれたら、迷わず「名前」だと答える。もちろん、人それぞれだし、自分はスキルの高いプログラマーじゃないよ、と前置きして。 　名前が9割と言ったときの、9割という部分は人によってだいぶ差があるんだと思う。もっと小さいかもしれない。けれど、名前が重要だという点に関しては、反対するプログラマーはいないんじゃないだろうか。 ## 時代や環境で変わる名前。 　いま僕がイメージしてる名前というのは、変数名だったり関数名だったりクラス名だったり、とにかくいろいろ。さらに、JavaScriptとか高階関数をバリバリ使うような場合など、名前をつけないという選択肢もある。 　なんとなくJavaScriptと書いたんだけど、名前はプログラミング言語や開発環境やハードウェアなんかの制約を受ける。Rubyだと、`group.member?` のように疑問符を使うことができて、boolを表現しやすかったりする。 　昔はハードウェアの制約？で、名前の最大文字数が短かったりして、省略した名前をつけたりしてたっぽい。いまはだいぶ自由に名前をつけることができて、さらに日本語の変数名や関数名を使える環境も増えてきた。 　Lispの変数名が長いのは、変数名にしか情報を乗せられないからとか、自動補完ができるからとか聞く。静的型情報を持つかどうかによって名前に持たせる情報量が変わってきたりする。あと、オブジェクト指向かどうかというのは違いが大きい。 　開発環境の進化も重要で、以前は変数に型を表すプレフィックスをつけるのが主流だったんだけど、いまはつけなくなったと思う。IDEが進化してマウスオーバーなどで型情報をかんたんに確認できるようになったからとも言われている。 　聞きかじりのうろ覚えなので、うそを書いてるかもしれない。興味がある人は調べてみたらおもしろいかも。 ## 時間をかけて名前をつける。 　名前に関する制約が少なくなったからこそ、しっかり名前を考えたい。適切に名前をつけさえすれば、プログラムは動く。言い過ぎ？何のオブジェクトなのか（どのクラスのインスタンスなのかという意味だけじゃなく）がはっきりわかるとか、メタ情報を見なくても関数の戻り値の型がわかるとか。単数形と複数形をしっかりと区別したり、受動態と能動態をしっかりと区別したり。そもそも、それ以前のコンセプト的な話でもあったり。 　適切な名前がついていると、可読性が高まるだけじゃなく、もちろん保守性も高まるし、バグも少ないし、開発生産性だって上がると思う。でも、ちゃんと名前をつけようと思うと、そこに時間がかかる。それでついつい妥協して名前をつけてしまって、結局また破れ窓理論の話になるけど、プログラム全体が残念な感じになってしまう。 　ガーッとコードを書いてるときに、いったん立ち止まって、名前について考える時間をとったほうがいいと思う。それこそエディタが進化してリファクタしやすいくなってるので、イケてない名前だと思ったら迷わずリファクタするといいんじゃないだろうか。放置してると後になるほどつじつまが合わなくなってしまう。 ## 発想を左右する名前。 　名前は発想につながる。この話になると「ヨシュアツリーの原則 (Joshua Tree’s Principle)」が必ず出てくる。もらった植物図鑑にヨシュアツリーという変わった形の木が出てくるんだけど、こんな木は一度も見たことがないと思って、外に出てみるといたるところにヨシュアツリーがあったという。その名前を呼んだことで、それを意識できるようになって、コントロールできるようになるという話。 　クラス図を書いたときに適切なクラス名をつけていれば、そのクラスが何をすればいいのか自然と導き出されることが多い。小説を書くときにキャラクターをつくったら、そのキャラクターが勝手に動きだして自然とストーリーができあがるというのに似てる気がする。まあ、僕は小説を書かないんでわからないけど。 　`Book` のコレクションに名前をつけるときに、 `Books` と `BookShelf` とでは、その後の発想がまったく変わってくると思う。そう考えると、プログラムを書く以前に、プロジェクト名というのは発想の方向性を決める重要な要素なんだろう。 ## 脱線。 　プログラミング言語はどれも同じだと言うプログラマーがいて、本当にそういうレベルに達している人もいるけれど、そうでない人もいる。僕はPHPのコードを書くこともあるんだけど、PHPの文化とか流儀にのっとって書いてない。なので、基本的に、PHPは書けませんと言ってる。 　言語によって表現力に差があって、名前に関して言えば、例えば名前をつけないという選択肢があるかどうかは大きな差だと思う。どの記号を使えるかも重要だし。名前に関わらず言語の力について考えると、ポール・グレアム的な話になって、宗教的な話になりそうなのでやめとく。話がそれるなあ。 　言語仕様に関しては、名前空間を使えるかも重要だし、予約語が気になることもある。クラスがメソッドの他にプロパティを持ってたりする言語だと、表現力が高くなる。あと、文化的背景？も影響があって、Camel形式かどうかとか、本質的な名前は変わらないにしても、雰囲気がだいぶ変わる気がする。 ![[6184932338_78483ab6a8_c.jpg|500]] ## 名前で品質をチェックする。 　デザイナー出身などプログラマーじゃない人がプログラマーを雇うパターンはかなり多いと思う。スタッフ数名くらいの会社をイメージしつつ。それで、雇ってる側がプログラミングぜんぜんわからん、というパターンもこれまた多いと思う。そうすると、プログラムの品質とか評価できなかったりするんじゃないだろうか。 　そこで、プログラマーじゃない経営者がプログラムやプログラマーを評価するときに、プログラム中の名前をチェックしてみるといいと思う。ロジックを追うのが難しくても、何が登場するのかを確認するだけならやりやすい気がする。 　HTMLがわかる経営者なら、idやclassの名前のつけかたがHTMLの評価基準のひとつになるのをイメージするといいかもしれない。たぶんそれより複雑なんだけど。プログラムがどう動いてるかではなくて、スナップショットを撮ったときに、どんなモノが登場しているか。 　デザイナー経営者の場合、フロントエンジニアに指示を出すことも多いんじゃないだろうか。JavaScriptは生まれつきコードがカオスになりやすい言語なので、とくに名前には気を遣うべきだと思う。まあ、フロントエンジニアって言ってみたかっただけなんだけど。 ## 例えばメタファを使うとか。 　適切な名前のつけかたについては、誰かが記事を書いてくれるんじゃないかと期待してる。ひとつ挙げると、メタファを使うというのは有効な方法で、抽象概念に抽象的な名前をつけるよりも、現実にあるモノの名前をつけるとうまくいくことがある。`Factory` とかがいい例だと思う。あと、デザインパターンの名前とかもそんな感じ。 　契約より契約書という名前にしたほうがいいかもしれないし、とにかくいろいろ当てはめてみると、何かが見えてくると思う。問題は、ハマってコードを書いてると立ち止まって時間を取ること疎かにしてしまうこと。ここはもう、時間をとるしかない。本当に名前で9割決まるのだとしたら、やるしかない。 ## 最新の記事を書いてください。 　個人的には、これだけ名前が重要だと言いながら、1箇所妥協して全体的に破綻するパターンが多くて、ダメだダメだと言い続けてる。結局、名前をつける時間をとってないのがダメなんだけど。ユニットテストの重要性は理解してるけど、テストコード書く時間をちゃんととってない的な。 　名前をつけるときのガイドラインであったりデザインパターンがあると、名前つけの時間を短縮できる気がする。ガイドラインとかネーミングルールはわりと見つかりやすい。それに加えて、名前つけのデザインパターンとか書いたらおもしろいと思う。流行り廃りもあると思うので、誰かモダンでナウいイマいヤングな記事を書いてください。 　あいかわらずカフェでだららだ書いて、まとまりもなく、「思う」「気がする」「かも」ばっかりだけど、それも含めてスシが食べたい。