明けましておめでとうございます！

はじめに

　何の因果か、２０２５年一発目のブログ記事を担当することになりました。よろしくお願いします。
　２０２５年の今年は蛇年ですね。私は近所の博物館に行って飼育員さんの指示の下、生まれて初めて蛇（アオダイショウ）を触らせて貰いました。キレイにならんだ鱗肌はスベスベ、横にならんだ白いお腹の鱗はとってもなめらかで、よく見ると可愛いお顔をしています。今年は蛇年、蛇は縁起が良い…ということで今年一発目のテーマはスネークケースについて思ったことを書いてみます。

名称について

　複数の単語を使った識別子の区切り文字にアンダースコアを使う命名規則は、コンピュータサイエンスの初期から存在していたはず。ではいつからこの命名規則が『snake_case』と呼ばれるようになったのでしょうか？
　調べてみたところ所説あるようですが、おおむね2000年代初頭からのようです。確かに自分が新卒の頃はただ単に「アンダーバー繋ぎ」「アンダースコア繋ぎ」と呼んでいて、特に支配的な呼び名は無かったように記憶しています。個人的には数ある呼称の中から、キャメルケースに対抗して、生物であるスネークケースが好まれ、やがて優勢になったのではないかと思います。

キャメルケースとスネークケース

　そう。スネークケースの最大のライバルといえばキャメルケースでした。最近ではそれぞれの言語で命名規則が固まって来て、きのこの山・たけのこの里論争のような派閥争いは見られなくなったように思います。ただUPPERCASE / lowercase の区別なく、実際に使用された数で考えると、Python の存在が押し上げてる感がありますが、過去の遺産が多いCやJava、JavaScript等において定数以外だとあまり使われていないことを考慮すると、スネークケースは劣勢のように思います。英語版の両者の Wiki の記事の量でもキャメルケースが圧倒しています。

定数

　ただやはりスネークケースの牙城と言えば定数ではないでしょうか。public static final String のスクリーミングスネークケース（アッパースネークケースを愛情を込めてこう言うそうです）の安定感は異常です。３か 3.14 かは世代的には議論があるかもしれませんが、const PI = 3.14; は心にゆとりが生まれます。
　しかし定数にアッパースネークケースへの不満も一部にはあるようです。だいたい以下に集約できます。
・通常の英文からの乖離や、キャメルケースと比べた時の長さから読みにくい。
・定数だけがアッパースネーク＝変数、関数名と一貫性がない
・immutable であることが保証されていないケースで定数としてアッパースネークケースを使うと混乱する
・IDEが区別するので命名規約で区別する必要ない
　最後のものはアッパースネークケースを規約に採用するのであれば、 const 修飾子の有無に関わらず、コンパイル時に不変でないものには使わないといったような細かいルールまで含めればいい話だと思います。
　プロジェクトや環境面からIDEや言語の選択が不可能なケースもあるでしょうし、一貫性は言語にも依存します。個人的には定数をアッパースネークケースで書くかどうかは各プロジェクトのコード規約の設計時に、それぞれの現状を考慮して決めるべきだと思います。ただ長いアッパーケースの読みにくさはガチですね。

長いアッパーケース定数

　今の会社に入る前のことですが、給与や会計系のプロジェクトに参加した際、定数が複雑な税関係の単語のローマ字表記のアッパースネークケースになって苦しめられたことがありました。事業所得控除額とか給与所得控除額の定数に"KYUUYO_SHOTOKU_KOJO_WARIAI"とか"KYUUYO_SHOTOKU_KOJO_GAKU"みたいな長い定数（実際はもっと長かった気がします）が大量に出てくるとトラップにしか見えなかったです。こういうケースだとそもそも英単語も分からないのですが、英語＋キャメルケースの方が見た目は少しマシかも知れません。ただこれはそもそも命名規則だけで複雑さが解消される問題ではないので、設計に問題がある気もします。なるべくスコープを小さくすれば多少は短い定数名で書けたのではないかと。

終わりに

　ここまで蛇くんたちのためにスネークケースの肩を持ってきましたが、そもそも命名規約はこの業界は長いものには巻かれた方が合理的なケースが多いので、僕はプロジェクト毎のルールに従います。すいません。
　それでは皆様、本年度もよろしくお願いします。