区切り文字を使わない命名規約で頭字語をどう綴るかについて

適当な頭字語、例えば「URI」を例に挙げる。あるプログラミング言語の命名規約で区切り文字のないケーシング（つまり-や_を使って語を区切ったりしない方式）を使うことになっているとき、このような頭字語を綴る方法は大まかに以下の二通りがあり、どうするべきか迷う人がいるかもしれない。

1. URI
2. Uri

筆者は常に2が望ましいと考える（camelCaseの場合は先頭は小文字となるが、あくまでそれは例外）。というのも、そのような識別子を、例えば試しにkebab-caseに直してみることを考えると、いくつかの問題が浮かび上がることがわかる。ここでは、データベースに格納されたURIを、より軽量な（整数などの）何らかのIDで一意に特定するという状況を考えてみよう。このとき、1の方式では、そのIDの型名を以下のように綴ることになる。

• URIID

そうしてこの識別子をkebab-caseに直そうとしたとき、おそらく求められるのはuri-idという形だが、この変換をURIIDという文字列の形態だけを見て機械的に行うことはできない。英語にそれぞれの単語（ここではURIとID）が存在し、この文脈ではおそらくこの位置で区切られるだろうという不確実な推測や背景知識なしには、kebab-caseに直したときに無意味な識別子（ここではu-r-i-i-d）が出来上がってしまう。1のように綴ってしまうと、区切り位置の情報が失われてしまうのだ。

逆に、区切り文字を使う方式で綴ったものを区切り文字を使わない方式に直してみることを考えてみてもいいかもしれない。uri-idを素直にPascalCaseに直すと、以下のようになる。

• UriId

2の綴り方でやった方が、命名規約間の整合性が保たれているのは一目瞭然である。

このような情報損失は、通常はあまり問題とはならないが、命名規約間を行き来するようなコードを書くときに、地味に厄介なささくれとなる。あるライブラリーやAPIの各言語用のバインディングを自動生成するようなケースがそれにあたる。特に嫌なのは、このようなまったく取るに足らない原因、たまたまオリジナルの命名者が考えなしに1のような情報損失的な綴り方を採用したことによって、下流の開発者が不当な開発体験の悪化を被ることになるかもしれない、という点だ。URIをパースするparseURI APIを呼ぶために、末端の開発者がparse-u-r-iのような異常文字列をタイプしなければならないという状況が発生する可能性は、あらかじめ2の綴り方を使っておけば回避できるのである。

草草