ラクダとヘビの、終わらない戦い — 2026年の命名論争

先日ネットを眺めていたら、「camelCase と snake_case、どちらを使うべきか【2026年版】」みたいなガイド記事に出くわしました。思わず、ふふっとなってしまって。2026年になっても、まだこれ書かれてるんだ。

そもそも何の「名前」の話?
2026年、いまも本気で議論している人たち
一方で、もう気にしていない人たち
たぶん、どっちも人間らしい
あなたはどうですか?

そもそも何の「名前」の話?

コードを書いたことがない方のために、まずここから。プログラムを書くときは、扱うデータやまとまりに、いちいち自分で名前をつけていきます。たとえば「利用者の名前」を入れておく入れ物に、getUserName とか get_user_name といった名前をつける。中身は同じ「利用者の名前」なのに、つづり方の流儀が2つあるんです。

単語の頭を大文字でくっつける getUserName が camelCase（キャメルケース）。でこぼこがラクダのこぶに似ているから、この名前です。単語をアンダースコアでつなぐ get_user_name が snake_case（スネークケース）。低く這うヘビに見立てています。ラクダか、ヘビか。名前からしてもう、なんだか可愛い対立ですよね。

そして、この「どっちのつづり方でそろえるか」で、エンジニアは長年ずっと言い合ってきました。私も昔、レビューのたびに「ここ、キャメルで userId? それともスネークで user_id?」と、チームでどっちに統一するかで軽く一悶着した口です。

2026年、いまも本気で議論している人たち

面白いのは、この論争がいまだに現役なこと。海外の技術コミュニティのコメント欄を覗くと、今日も元気に言い合っています。せっかくなので、原文のまま少し引用させてください。

まず多いのが、「好き嫌いじゃない、その言語の慣習に従え」という立場。

“it’s not a matter of which one I like best, it’s a matter of following the code conventions of the language I’m writing”

どれが一番好きかの問題じゃない。自分が書いている言語のコード規約に従うかどうかの問題だ。

“it’s just better to go with language conventions than to fight the community norms”

コミュニティの規範と戦うより、言語の慣習に乗るほうがいいだけ。

次に、「とにかくコードベースの中で一貫していればいい」という現実派。

“Doesn’t matter to me as long as the codebase is consistent. If I truly had to pick one I would say camelCase”

コードベースが一貫してさえいれば、どっちでもいい。どうしても選べと言われたら camelCase かな。

そして、「読みやすさこそ正義だ」と研究まで持ち出す人。

“A study shows that people find it easier to read ‘snake_case’ than ‘camelCase'”

ある研究によれば、人は camelCase より snake_case のほうが読みやすいと感じるらしい。

さらには、「両方使い分ければいいじゃないか」という人まで。

“I use camel case to name my functions and i use snake case to name my variables”

関数の名前は camelCase、変数の名前は snake_case で付けている。

……二十年前と、ほとんど同じ会話が続いています。しかも、みんな真剣です。

一方で、もう気にしていない人たち

ところが、同じ2026年に、まったく逆の空気もあります。AIにコードを書かせるのが当たり前になった現場では、「命名? AIと整形ツールが勝手にそろえるでしょ。自分は動くかどうかしか見てない」という声が、静かに増えています。保存した瞬間にツールが全部そろえてくれるので、そもそも悩む場面が来ない。

この空気を象徴するのが、「vibe coding（バイブコーディング）」という言葉を作った Andrej Karpathy さん（元Tesla AI責任者）の、有名な一節です。命名どころか、コードの中身を見ること自体を手放した、と言い切っています。

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. … I ‘Accept All’ always, I don’t read the diffs anymore.”

「vibe coding」と呼んでいる新しいコーディングがある。雰囲気に完全に身をまかせ、指数関数的な進歩を受け入れ、コードが存在することすら忘れる。……いつも「Accept All（すべて承認）」で、もう差分は読まない。

この「もう論争しない」側の声も、原文で拾ってみます。チームからスタイル論争を消したという、整形ツール Prettier の体験談から。

“No more style debates: We literally can’t argue about code style anymore — Prettier decides.”

もうスタイル論争は起きない。文字どおり、コードスタイルのことで言い争えなくなった。Prettier が決めるから。

“If you’re still manually formatting code or spending PR reviews discussing style, you’re wasting time that could be spent on actual problems.”

いまだに手で整形したり、レビューでスタイルを議論しているなら、本当に取り組むべき問題に使えたはずの時間を無駄にしている。

「二十年変わらず本気で揉め続ける世界」と、「まるごと関心が消えた世界」。それが並んで存在している。これがなんだか、じわじわ面白いのです。

たぶん、どっちも人間らしい

揉めるのも、気にしないのも、私はどっちも人間らしいなと思います。揉めるのは「チームで意味をそろえたい」という律儀さの表れだし、気にしないのは「本質はそこじゃない」という割り切りの表れ。どちらが正しいという話ではなくて、大事にしている場所が違うだけ、という気がします。

ただ、ひとつだけ分解しておくと——命名の悩みそのものは、たぶん消えていません。引っ越しただけです。昔は、人と人がレビューの席で表記をそろえていました。いまは、AIに書かせる前に「このプロジェクトはこの規約で」と先に指示として渡す。悩む場所が、人と人のあいだから、人とAIのあいだへ移動した。舞台が変わっただけで、「意味をそろえたい」という気持ちは、案外そのまま残っている気もするのです。