W.I.S. Laboratory
menu-bar

プログラミング時の命名


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

プログラミングの世界には「キャメルケースとスネークケースはどっちが優れているのか論争」というものがある。(勝手に名付けた)
私自身はどちら派でもない。
コーディング規約やネーミング規約があればそれに従うし、無ければあまり意識せず言語ごとに書き分けている。

スネークケースとは

this_is_snake_case

というように、全て小文字で書きアンダースコアで区切った記述法のこと。
見た目が蛇のようだから、というのが語源のようだが、「スネイルケース」が訛ったものだという説もある。
スネイルはカタツムリ。
そう言われてみると、カタツムリのように見えなくもない。

キャメルケースとは

thisIsCamelCase
ThisIsPascalCase

というように、記号を使わず基本は小文字で書き、大文字を区切りとして使った記述法のこと。
見た目がラクダのコブのようだから、というのが語源らしい。
特に先頭が小文字のものを「キャメルケース」「ローワーキャメルケース」と呼び、先頭が大文字のものを「パスカルケース」「アッパーキャメルケース」と呼ぶ。
パスカルケースの「パスカル」はプログラミング言語のPascalからきている。
Pascalではアンダースコアが特殊記号として予約されているわけではないのだが、慣習的に変数名や手続名に記号を混ぜることを好むプログラマーがあまりいない。
さらにPascalでは大文字と小文字の区別がされないため、「thisispascalcase」を「ThisIsPascalCase」と書いても同じ変数や手続として扱われる。
結果、読みやすくなるメリットしかないのでこのような書き方が普及したのだろう。
余談だが、Windowsを作り始めた頃のマイクロソフトはパスカルケースを好んで使っていたようで、WindowsAPIの関数名はパスカルケースで書かれている。

あと「ケバブケース」

this-is-kebab-case

それに「アッパーケース」

THIS_IS_UPPER_CASE

というのもある。
ケバブケースはスネークケースのアンダースコアがハイフンになった記述法だ。
見た目が肉を串に刺して焼いた料理「ケバブ」のようだから、というのが語源らしい。
鎖で繋いだようにも見えるからか「チェーンケース」と呼ばれることもある。
ウェブサイトに使う画像などのファイル名やCSSのプロパティの命名規則としてよく採用されている。

アッパーケースはすべて大文字で書いたものをスネークケースの要領で繋げたものだ。
その名の通り「全部が大文字(アッパーケース)で書かれているから」というのが語源だ。
頻繁に定数を表すのに採用されるためか「コンスタントケース」と呼ばれたり、区切りがスネークケースと同じなので「アッパースネークケース」と呼ばれることもある。
データベースのテーブル名やカラム名に使われたりもする。

一般的ではないが「アッパーケバブケース」

THIS-IS-UPPER-KEBAB-CASE

というのもあるにはある。
アンダースコアが特殊記号として予約されているような環境で、マクロや定数を表すのに使われる。
プログラミング言語ではないが、MMLコンパイラのSPICEで、組み込みマクロ名に採用されていた。

ケバブケースは、ハイフンがマイナスとして認識されてしまうためほとんどのプログラミング言語では使えない。
アッパーケースがプログラミング言語で採用されるのは定数を表すときくらいで、その慣習はどういうわけか多くの言語に共通している。
そのためか、これらはプログラミング言語における「どっちが優れているのか論争」に巻き込まれることはあまりない。

世の中にはたくさんのプログラマーがいて、変数名や関数名をどのように記述するのが良いことなのかと、人それぞれの主張がある。
そもそも大昔はスネークケースもキャメルケースも無く、適当に省略した名前を付けていた。
メモリも少なく画面も狭かったので、変数名や関数名は短いに越したことはなかった。
また変数名や関数名に記号を混入することが一般的ではなかったし、Cなどの大文字・小文字を区別する言語ではどちらかに統一したほうが良いという風潮があった。
なので初期の標準Cライブラリなど、ひと目見ただけでは何を意味しているのか、なんと発音すればよいのかも分からないものもたくさんある。
当時プログラムというものは一人で書くものだったので、自分に分かりさえすればそれで良かったのだ。

しかし時代が進み、プログラムは一人で書くものではなくなってくる。
そこで誰が見ても分かるように、適当に省略することなくちゃんと変数名や関数名を付けよう、ということになってきた。
とはいえ小文字ばかりで冗長に書いてしまうと、どこが単語の区切りなのか分からなくて読みにくいので、「何かで単語を区切ろうぜ」となるのは当然の流れだ。
そのときに英語と同じくスペースで区切ることができれば、こんな論争は生まれなかった。
だが多くのプログラミング言語では、変数名や関数名の間にスペースを入れるとエラーになってコンパイルできなかったのだ。

そこで多くの言語で特殊記号として予約されていなかったアンダースコアを挟み区切りにするスネークケース派の人と、基本小文字で書いて大文字を区切り代わりにするキャメルケース派(というより当時はパスカルケース派)の人に分かれた。
それぞれの言い分には「○○ケースのほうが読みやすい」という主張が多いような気がするが、読みやすさというのは主観であってその人の好みと慣れだろう。
「こっちの店のラーメンのほうが美味しい」というのと同じで結論が出ない。

「どちらでも良いが、プロジェクト(パッケージ)単位で統一すべき」という意見もある。
分からなくもないが、古い言語で複数のライブラリを混在して使うと意図せずごちゃごちゃになる。
例えばC++で標準ライブラリを使いつつWindowsAPIを叩くようなコードを書ただけでも、スネークケースとパスカルケースが混ざってしまう。
それを統一しようなどとしても焼け石に水だし、時間も手間もかかった上にしなくてもいいデバッグ作業に追われる羽目になる。
統一するために多大な時間と労力がかかるのであれば、そこまでする必要はない。

比較的新しい言語でライブラリも記述が統一されているものであれば、それに合わせて統一するのが最好手だという意見もある。
これも理解はできるのだが、息を吐くように組み込みクラスや組み込み関数を増やしてくる言語もあるのだ。(動的型付け言語に多い気がする)
名前空間で区切られているならまだしも、新しくなるたびにグローバルスコープの組み込み関数が増えてくるような言語だと、ある日突然自分が昔作った関数と名前がぶつかってしまうかもしれない。
C++で「using namespace std;」をやってしまっても同じことが起こる。(なのであまりしないほうが良い)
こういった言語で何か書く場合、例えば組み込み関数がスネークケースを採用していたら、逆にキャメルケースで書くことによってそのリスクが軽減できる、というメリットもある。
また、あえて組み込み関数とは違う記述をすることで、後でコードを読み返したときに、そこで呼び出している関数が言語組み込みなのか自作関数なのかをひと目で区別できるという点もメリットになることがある。

また比較的新しい言語に多い気がするのだが、「基本的にどちらで書いてもいいんだけどクラス名や構造体名の最初の1文字は必ず大文字にしてね」という言語もある。
これに慣れてくると、スネークケース派の人でもクラスの命名をするときだけはパスカルケースで書くようになってくる。
おそらくこのような言語の影響だと思うが、最初が大文字で以後は小文字のアンダースコア区切りで

This_is_no_name_case

という、まだ名前がついていない新しい書き方も出てきた。

個人的には、スネークケース・キャメルケースの完全統一にこだわる必要は無いと思うし、こだわりすぎると変な疲れが出てくるように感じる。
それにスネークケースしか書かない人はGoで外部パッケージから呼び出せる関数が定義できないし、キャメルケースしか書かない人はRustの変数が宣言できない。
「この言語は組み込み関数が○○ケースだから」「この言語は○○ケースを強要してくるから」という理由で、腕のいいプログラマーが優れた言語を避けてしまうのは、あまりにもったいない。

また書き方を全部統一すると、見た目はたしかに綺麗になるのだが、「ひと目でそれが何かを見分ける」ことが難しくなる。
CやJavaなどを書く人の中には、if や for とパーレンの間にスペースで隙間を作り(if (x == 2) { ... } など)、関数の後のパーレンは隙間なし(myfunc();など)で書いている人がいる(私もそうだ)が、これはひと目で構文と関数を見分けられるようにするのが目的だ。
変数とメソッドはスネークケース、クラスと構造体はパスカルケース、という具合に書き分けることは「ひと目で見分けられる」という点ではメリットになる。
そういった目的のためならば、「定数はアッパーケース、クラスはパスカルケース、メソッドはキャメルケース、変数はスネークケース、連想配列のキーはケバブケース」という具合に書き分けるのもアリなのかもしれない。(極論だとは思うし私はやりたくないが)

いろいろ書いたが、何か新しくコードを書くときにそのプロジェクト(パッケージ)内で自分(達)が命名するものの記述法は統一したほうが良いのは絶対だ。
同じ人(チーム)が書いているのに、あっちの変数はキャメルケース、こっちの変数はスネークケース、という書き方は嫌われる。
ただし、クラスはすべてパスカルケース、変数はすべてスネークケース、という書き方は嫌われない。
命名というのはその時の気分でデタラメにやっていいわけではない、という点はキャメル・スネーク両派が共通して持っている感覚だと思う。
プログラミング歴の長い人で、これに異論のある人はまずいないだろう。(特殊なケースはあるかもしれないが、それは納得のいく理由に違いない)
数年後の自分(達)がコードを読むときのためにも、他の人に読んでもらうときのためにも、そこは大切だと思う。


[ 戻る ]
saluteweb