半角スペースのない世界

コンピューター内部において、半角スペースというものは大概特別な意味を持つ。

ファイル名に半角スペースを入れると、特定のソフトウェアによって正しく認識されないフールプルーフが徹底されていない場合の話である。伝統的プログラミングにおいて、プログラム的に正しくない入力を避けることはユーザ側の義務であった。 [annotation: フールプルーフが徹底されていない場合の話である。伝統的プログラミングにおいて、プログラム的に正しくない入力を避けることはユーザ側の義務であった。] というような話を耳にすることがある。

そういったソフトウェアは暗黙的にファイル名における半角スペースを禁止している、とくに複数のファイルをまとめて入力する場合のセパレーター記号として扱われていることが大半だろう。

しかしながら、コンピューター世界の第一言語は英語少なくとも人間にとっては。 [annotation: 少なくとも人間にとっては。] であり、半角スペースがなければまともに文章や熟語を表現することはできない。

ではどうすればよいのか、コンピューター史初期の開発者たちはこれを命名規則という概念を用いて解決した。

これは単純に半角スペースの代わりとなる記号や記述法を導入するというだけである。

例としてHello Worldという識別子一意な要素名のこと。変数名、型名、クラス名など、プログラムの中で名前がついているものは大体これである。ここではファイル名やウェブドメイン名なども厳密には異なるものだが近しいものとして同様に扱う。 [annotation: 一意な要素名のこと。変数名、型名、クラス名など、プログラムの中で名前がついているものは大体これである。ここではファイル名やウェブドメイン名なども厳密には異なるものだが近しいものとして同様に扱う。] を考えてみよう。

当然だがそのままHello Worldと記述しては、前述した半角スペースの問題は解決しない。最悪HelloとWorldに分割して扱われるか、そもそも認識すらされない場合もあるだろう。

ここで半角スペースの代わりにアンダースコアを置いてHello_Worldとしたり、ハイフンを置いてHello-Worldとすることで語の視認性を維持しつつ、プログラムの処理を妨げないようにするというわけだ。

個人的に一番よく見かけるのはHelloWorldやhelloWorldのように小文字と大文字のギャップによって視認性を確保する手法である。

これらにはもちろん名前がついており、アンダースコアを介するものはスネークケース（Snake case）、ハイフンを用いるものはケバブケース（Kebab case）、最後のパターンはキャメルケースとくに例の前者、HelloWorldのようにすべての頭文字を大文字にするパターンはパスカルケース（Pascal case）と広く呼ばれている。 [annotation: とくに例の前者、HelloWorldのようにすべての頭文字を大文字にするパターンはパスカルケース（Pascal case）と広く呼ばれている。] （Camel case）と呼ばれている。

それぞれに大文字・小文字の表記ゆれがあり、たとえばhello_worldもHELLO_WORLDも同様にスネークケースである。

にらみあい

さて、ただ単に命名規則の種類を列挙して「いかがでしたか？」などと言いたいわけではない。

これら半角スペース代用の命名規則には大きな、かつ滅多に話題にあがらないような隠された問題がある。

それはすべての場合に適合する最良のものが定まっていないということだ。

たとえばファイル名やウェブドメイン名には慣例としてケバブケースが使用される。

一方、多くのプログラミング言語でケバブケースを用いた命名は禁止されている。これはハイフンという記号がマイナスの計算記号という強い役割を持つためだ。

しかしながら、こういう都合があるというのに、依然としてファイル名などにおけるケバブケース使用は取りやめられることはない。

何なら、ケバブケースで定められた識別子を自動でスネークケースに変換する実装さえある。

これは別にそうすべきと定められているわけではなく、他の命名規則であっても問題はないはずである。

どう考えても、この場合ならスネークケースで統一すべきではないかと思う。

そういった理屈が通用しないほどに慣例の持つ強制力というものは凄まじいものなのである。

ファイル名やウェブドメイン名の命名はケバブケースという前提のもと世界は回っているのだ。

他のプログラミング言語やそれを取り巻く環境においても、命名規則の慣例は強く根付いている。

それぞれには派閥があり、キャメルケースを重宝する言語やほぼすべてをスネークケースで済ませる環境、さまざまな種類の命名規則を織り交ぜた環境など多種多様である。

それらは閉じた環境で一貫した命名規則を持つだけであるため、先の例のような競合が直接発生することはない。

とはいえ、ある言語の使用者が他の言語を学習し始めるとき、ほぼ確実に命名規則由来の違和感や覚え間違いに遭遇するのではないだろうか。

すなわち最初に学んだ言語、もしくはもっとも高い頻度で使用する言語の命名規則に手や頭が引っ張られることは、誰しもが経験しうることだと考える。

これらは乱立する命名規則の悪影響だと言えなくはないだろうか。

たとえそうだとしても、最良の命名規則がない以上、開発者たちはそれを探し求めて乱立を続けるしかないのであろうが。

追記～組み合わせ

最良の命名規則は存在しないと述べたが、それは最良の命名規則の組み合わせが存在しないということを意味していると明記しておく。

1つの命名規則を使い倒すということはもはや主流ではなく、とくに複数の命名規則を組み合わせることが前提となっている。

多くのプログラミング言語でそうであるように、ある種のタグとして命名規則を扱うという手法が可能であるためだ。

たとえばケバブケースの識別子を見たとき、それがファイル名やそれに類するものである可能性が高い、などという判断が可能になる。

何なら後述の話題はすべてこの考えを前提としている。

なお前述の論調については、ケバブケースという命名規則が多くの領域で禁止されているというのに一般化している現状が、それらの領域においてゆがんだ組み合わせを生んでしまうあるプログラミング言語において、ディレクトリ名を直接示す識別子名（プロジェクト名とディレクトリ名が等しい場合など）をスネークケースで表記せざるを得ないなど。 [annotation: あるプログラミング言語において、ディレクトリ名を直接示す識別子名（プロジェクト名とディレクトリ名が等しい場合など）をスネークケースで表記せざるを得ないなど。] ということを問題視しているものである。

個人的な好み

さて、最良の命名規則がない以上あとは好みの範ちゅうである。

ここで私、筆者個人の考える最高の組み合わせを紹介しよう。

主に想定するのはプログラミング環境だ。実際の言語には明確な命名規則があり、それに従うことが何より正しいことであるため、一切の縛りがない空白の環境という体でリストアップする。

なお命名規則の名称をその命名規則にしたがって記述する。

• 型やそれに類するものはCamelCase（PascalCase）
• 変数名や関数名など、束縛する必要があるものはsnake_case
• 定数やその他の使用頻度が低い識別子はSNAKE_CASE

これはほとんどRust言語の用例と等しい。

この命名規則の優れた点は、それぞれの表記法がある程度離れているということである。

逆に表記法が極端に近い例をあげよう。

具体的に型名がPascalCaseのとき、変数名がcamelCaseである場合を考えると、これらが同名である型名HelloWolrdと変数名helloWorld [annotation: 型名HelloWolrdと変数名helloWorld] ならば、両者の差は先頭1文字のみである。誤差の範囲かもしれないが、やや視認性に劣るように思われる。

Helloとhelloのようにそもそもこれら命名規則の影響下にない場合も同様であるが、個人的に長い識別子で間違い探しをすることはあまりにも苦痛である。さらに言えば、エディターの自動推測からピックアップする際にも、間違えたものを選んでしまいかねない。

現代のプログラミングは基本的にエディターの自動推測やAI機能を最大限生かしつつ行うものだ。

こうした視点で見ると、表記が近い命名規則の混合を避けるべきだといえる。

定数を含めたその他の使用頻度が低い識別子についても、方針は大きく変わらない。

SNAKE_CASEを記述するコストは高いが、その分他の命名規則とは明らかに異なる表記をしているため、これらに最適プログラミングにおいて、使用頻度が低いことは重要であることを意味する。 [annotation: プログラミングにおいて、使用頻度が低いことは重要であることを意味する。] である。

以上、個人的な命名規則の好みであった。

環境適応

どこまで行ってもこの話題は、インデントの深さや括弧周辺の改行位置軽々しく触れてはいけない領域。フォーマッターの発達に伴い、表に出ることは少なくなった。 [annotation: 軽々しく触れてはいけない領域。フォーマッターの発達に伴い、表に出ることは少なくなった。] のような、いわば執念でしかやりとりできないものである。

使いにくいからと言って無理やり周りを合わせようとするよりも、素直にその環境のガイドラインに従ったほうがたいていの場合でうまくいくだろう。

もしくは、命名規則から使うプラットフォームやプログラミング言語を決めるのもおもしろいかもしれない。