お久しぶりです

こんにちは、クレスウェア株式会社の奥野賢太郎です。筆者はかつて株式会社ピクセルグリッドの社員であり、CodeGridの連載を持っていたこともありました。今回、独立後8年ぶりとなる執筆のご依頼を請け、こうやってシリーズを任されたことを嬉しく思います。

筆者は「リファクタリングとともに生きるラジオ」というエンジニア向けポッドキャスト番組にて毎週配信しており、そこでもリファクタリングや開発哲学について話しています。

今回はその経験から、プログラミングにおいて特に奥深いテーマである「名付け」についてお話ししていきます。「名付け」とは何を考え、何をすることなのか、一緒に考えていきましょう。

名付け慣れていますか？

コードの中には多くの名前があります。変数名、関数名、クラス名……、さらに視野を広くするとファイル名、ディレクトリ名、パッケージ名、リポジトリ名など。あらゆるプログラムは膨大な名前の集合体であるという側面があります。そのため、プログラミングのかなりの部分で、我々はなんらかの名前と向き合うことになります。

既存のコードを読んでいく場合には、多くの名前をひとつひとつ認識しながら構造を把握することになりますし、それが新規コードを書き下ろす段になると「他人が構造を把握できるような名前」をあなたは何度も何度も名付けることになります。プログラミングを実践する上で、常に付きまとう作業が「名付け」です。

「名付け」というと、格式高い印象を持つ方もいるかもしれません。たとえば、子どもが生まれたとき、家族にペットが増えたときに行うイメージがあります。一生使う名前を付ける行為です。

ところが、プログラミングにおける「名付け」は性質が異なります。愛情や感情、文化的な側面ではなく、プログラム全体の把握の補助が目的です。改名を頻繁に実施することもまったく咎められることではなく、それどころかリファクタリングの代表的な手法のひとつです。プログラミングにおける「名付け」は、まず人名やペット名とは、まったく切り離して考えます。

どうしてこんなことをわざわざ言うのかというと、プログラミングにおける「名付け」とはどういう「行い」なのかピンとこないままでいると、何度も繰り返し変数や関数を名付けたとしても、良い名付け、悪い名付けがわからないままになってしまうからです。

次の節から、プログラミングにおける「名付け」はそもそも何をすることなのか見つめてみましょう。

名付けはコミュニケーション手段である

前節でも触れたとおり、既存のコードを読む時間の大半はあらゆる種類の名前を見て構造や流れを把握する時間です。関数名を見て、引数名を見て、処理を追ってみると変数名が何種類も出てきて、別の関数を呼んでいればその関数名から挙動を推測して……。コードを読んでいる時間のなかで、名前に触れていない時間のほうがわずかだったりします。

大量の「名付けられたもの」をひたすら読んでいくなかで、あなたはあらゆる値、プロパティ、条件などを区別しています。名付けが適切であればあるほど、区別しやすさがあがり、全体の把握も容易になります。逆に名付けがずさんであると、値の区別がつかず、処理の推測ができず、条件分岐の組み合わせが想像しにくくなります。

つまり名付けの良し悪しには、自分が良い名前を付けられたと満足できるかどうかより、むしろ他者が「このコードは良い名前ばかりで構成されている」と評価できるかという側面があります。

補足：良い名前ばかりで構成されている

これが俗に言う「読みやすい」コードの一要素となっています。

プログラミングにおける「名付け」は、区別するためのラベルであり、そのラベルは他の開発者とのコミュニケーション手段となります。

塩と砂糖の区別

プログラミングにおける「名付け」は、区別するためのラベルというのを、実生活の上で考えてみましょう。台所の棚に2つの小瓶があります。そのどちらにも白い粉末が入っているとします。慣れていれば、粒の大きさや光の反射で中身を識別できるかもしれませんが、多くの人にとって、これが塩と砂糖のどちらであるか、紛らわしいと思います。

そこで台所で手際よく調理ができるよう小瓶に「塩」「砂糖」と書かれたラベルを貼ります。そうすることによって、小瓶の中の粒を観察しなくても、その中身は塩である、砂糖であると確信をもって扱うことができます。プログラミングの名付けはこの「ラベルを貼る」感覚にとても近いです。

調味料の例で見れば、このラベルは家族のため、あるいは飲食店であれば厨房で働く同僚が間違えないようにするためにも貼られます。つまり「家族」や「厨房で働く料理人たち」という組織ごとに、その組織内のみんなが作業中に間違えないようにするために付けられます。

プログラミングの変数名、関数名、ファイル名、その他あらゆる名前もその側面があります。一緒に働くエンジニアたちが作業を間違えず、なめらかに進められるように、区別のためのラベル貼り——すなわち名付けを行うのです。

一人暮らしなら塩・砂糖ラベルを貼らなくても大丈夫かもしれません。ですが自分用だとしてもパッと手に取る時、ラベルがあったほうがわかりやすいですし、何より取り違えて味が台無しになってしまうと悲しいですね。

プログラミングも同様で、自分だけだからと思って区別できない状態で放置しておくと、何かの拍子に取り違えて予期せぬバグを混ぜてしまうなど、悲しい事態につながることが考えられます。他人とのコミュニケーションとは言いましたが「過去の自分は他人」ともよく言ったもので、自分の作業をなめらかにするためにも、よい名付けが助けになるでしょう。

「危険」を伝える

おもしろい名付けの例を紹介しましょう。まさにコミュニケーションのために「こんな名前をつけてもいいんだ」と気付かされる例です。

ReactではdangerouslySetInnerHTMLというAPIが存在します。これはHTML文字列を直接DOMに挿入するためのプロパティです。しかし、この機能にはセキュリティリスクが潜んでいます。

通常、Reactは開発者が記述したテキストを自動的にエスケープすることで、XSS（クロスサイトスクリプティング）攻撃から保護してくれます。たとえば、<script>タグが含まれている文字列を描画しようとしても、それはスクリプトとして実行されず、>script<のようにサニタイズ（文字列を安全にするための加工）され、単なるテキストとしてDOMに挿入されます。

ところがdangerouslySetInnerHTMLというAPIを使用すると、Reactのサニタイズが無効化されます。渡されたHTML文字列はエスケープされることなく、そのままブラウザによって解釈・実行されるのです。もしユーザー入力や外部から取得したデータを、開発者が適切にサニタイズせずに渡すと、悪意のあるスクリプトが実行されてしまう可能性があります。

このような危険性があるため、Reactはあえてdangerouslyという警告的な単語をAPIの名前に含めています。Web標準であるinnerHTMLプロパティ自体もXSSのリスクはありますが、Reactの場合は原則的にサニタイズを実施することから、サニタイズが実施されないプロパティについて危険性を強調する必要があり、このような長い名前になったと推測しています。

また、Reactにはかつて内部用のプロパティとしてSECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIREDというものがありました。内部用であるためReactそのものを開発している開発者以外は触るなという意図で名付けられていますが、YOU_WILL_BE_FIRED（解雇される）という言い回しがジョークに見え、SNSでおもしろさとして取り上げられていました。

結果的に、この名前にしていてもなお外部から使われていたせいで、より具体的に警告する名前_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADEに改められました。名付けはコミュニケーション手段であることがよくわかる例です。

名付けの歴史は深い

プログラミングをすると繰り返し「名付け」と付き合い続けることになりますが、名付けはプログラマー特有の苦悩なのでしょうか。名付けを歴史的に振り返ってみると、それが人類の文化や技術の発展を支えてきた営みであることが見えてきます。

有史において、名付けによって区別可能にされた代表例として「地名」があります。地名には多くの示唆が詰まっており、そこには地形の高低や地質、災害の多さに対する区別が込められます。「谷」や「沼」と付いた地名はその代表例です。静岡県駿河湾沿いの「大崩海岸」はインパクトの強い地名ですが、その名の通り何度も崩落事故を起こしているという、はっきりと性質が区別できる地名であることがわかります。

科学分野や法律分野でも名前は重要です。

化合物の命名法を国際的に定めたIUPAC（アイユーパック）命名法はプログラミング以外の「名付け」を観察する上での好例です。命名規則が標準化されているおかげで、世界で未発見の原子番号119番の元素に「ウンウンエンニウム」と名付けることができます。これは原子番号の数字をラテン語に置き換えた仮名で、実際に発見される際には、改めて名付けられるのが通例です。たとえば原子番号113番の元素は従来「ウンウントリウム」で、日本人によって発見されてから「ニホニウム」と名付けられました。命名規則が定まっていることによって未発見の元素について学者の間で呼び名に差が生じないことは興味深い点です。

また、法律分野では契約書の多くに「甲乙丙」が用いられているものを読んだことがあるかもしれません。この甲乙丙はまさしくプログラミングにおける変数名に近く、複数の社名や人物が出てくる契約書において、冒頭以外では甲乙丙で区別することで、契約書の編集コストを下げ、登場する固有名詞が互いに似ていたり、長すぎたりしても区別しやすくしています。契約書に不慣れだと「わざわざ甲乙丙にしなくても……」と思うかもしれませんが、士業の専門家であればむしろスラスラと読んでいたりします。これは「どの組織において区別しやすいか」が重視された形態とみることができます。

良い名前って難しい

プログラミングにおいて「良い名前・悪い名前」というのはしばしば議論され、書籍や記事の題材になりやすいです。そして「良い名付け」をするべく「良い名前とは何か」を求めて記事や資料を検索されることもあるかもしれません。

本シリーズでは期待に反してしまうかもしれませんが「これが良い名前ですよ」あるいは「これが悪い名前ですよ」という見本集にはするつもりがありません。そうではなく読者一人ひとりにとって「良い名前ってこういうことなのかも……」と自分で気付くようになるための考え方や価値観に触れていただきたいと考えています。良い悪いに限らず、多様な名付けの例に触れることによって、こういう名付けは自分も真似したいと思える引き出しをたくさん増やしてもらいたいです。

第1回目では、プログラミングにおける名付けは人名・ペット名の名付けとはまったく異なり、開発者間の把握を補助するため、あるいは意図を伝えるため、危険性を警告するため、そういったコミュニケーション手段として使われていることを学びました。

次回は、この前提をもとに、業務の実際の例を取り上げてより実践的な名付けについて考察しながら、いい名前とはなんなのかという価値観を深めていきます。それでは、ありがとうございました。