名前があったなあ

文法面や、動作速度の面からはあまり重視されない「名前」ですが、人間とコードの接点では重要な役割を果たします。

名前と規約

ふつう、プログラムコードと名前は独立なものですが、ときおり名前と動作が結びついている例があります。

• Ruby on Railsでは、Userと名付けたモデルが自動でusersテーブルを参照するようになるなど、「設定より規約」のコンセプトが貫かれているので、名前だけでかなりのことが進んでいきます。
• JavaのJavaBeanでは、アクセサメソッドにgetやsetといった接頭辞をつけることとなっています。

このような規約がある場合、それを外れるよほどの理由がなければ、素直に従うべきでしょう。

名前による、暗黙のアノテーション

Reactのクラスコンポーネントには、以下のようなメソッドがあります。

• render
• componentDidMount
• componentDidUpdate
• componentWillUnmount
• getDerivedStateFromProps
• getSnapshotBeforeUpdate
• shouldComponentUpdate

このうち、かならず使うのはrenderで、componentで始まる3つをその次の頻度で使います。そして、残り3つは、それより使う頻度が落ちます。「あまり使わないものに長い名前をつける」ことで、直接的ではないですが使いにくくしています（なお、これからの構造変更に対応できなくなったメソッドはUNSAFE_componentWillUpdateのように、その旨を明示した名前となっています）。

名前をつけることで、存在を際立たせる

プログラムのリファクタリングにおいて、よく「共通部分を1つのメソッドやモジュールに切り出す」ということが行われます。もちろん、同じ処理を重複して書かなくて良くなるという効果が大きいのですが、副次的なメリットとして「切り出した部分に、単体の名前がつく」ことも1つの効果だと考えています。「このメソッドのこの部分」で呼ぶより、「このメソッド」と名前がついたものとして存在していることで、より注目もされるようになります（テストもやりやすいですし）。

直接コードを書く場面の話題ではないのですが、「Ajax」とか「JSONP」といった技法は、それまでに存在していた技術の組み合わせに新たな名前を付けて、それが定着したものです。検索エンジンでも抽象的な概念や、記号類は検索がうまく進められませんが、その概念に名前があれば検索もしやすいですし、議論の際にも言及しやすくなります。演算子なども、名前で検索すれば、いろいろ情報が出てきます。

逆を返せば、「名前が定着している」技法はそれだけ受け入れられている（あるいは、少なくとも議論の対象となっている）という指標にもなります。