snake_case への変換方法と、使うべきでない場面
snake_case は小文字の語を 1 つのアンダースコアでつなぐ表記で、user_profile のように書きます。Python の変数と関数、Postgres の列名、YAML や env のキーは、おおむねこの形です。
アンダースコアを使うべき場面
よくあるのは構成が分かれたときです。JavaScript 側は userName、Python のバックエンドとデータベースの列は user_name で、どこかで変換が必要になります。テーブル設計、ORM モデル、設定キーの整理をまとめて下線形式にしておくと、変換層の例外が減ります。
もう一つは古い名前の正規化です。旧システムから書き出した見出しは大文字、スペース、ハイフンが混在し、SQL でも ORM でも扱いにくくなります。小文字と下線に揃え、記号を落としておくだけでも、その後のクエリや移行スクリプトが書きやすくなります。
- Python の変数、関数、モジュール名
- データベースの列名やインデックス名（user_id など）
- YAML、env、設定ファイルのキー
- 古い出力の混在した見出しを 1 つの表記に揃える
どこで分割し、どこをまとめるか
キャメルケース変換との違いは、まず「小文字か数字 + 大文字」の境界で語を分割する点です。そのあと全体を小文字にし、英数字以外の連続を 1 つのアンダースコアにまとめ、両端の余分な下線を削除します。userProfile が user_profile になるのはこのためです。
細かい点が 2 つあります。連続した区切りは 1 つにまとまるため、a b も a--b も a_b になり、空の要素はできません。数字はそのまま残り、version2 は分割されません。漢字はここでの英数字に当たらないため削除されます。意味を残したい場合は先に英訳してください。
- キャメルの境界は分割される（userProfile → user_profile）
- 連続する区切りは 1 つにまとまり、空の要素はできない
- 先頭と末尾の下線は削除される
- 数字は分割しない（version2 はそのまま）
- 漢字は削除されるため、先に翻訳する
使うべきでない場所
URL のパスや CSS のクラス名は、下線ではなくハイフンが一般的です。Google はハイフンを語の区切りとして扱い、下線は扱わないと明示しており、/user-profile のほうが語に分解されやすくなります。リンクやクラス名を作るときはケバブケースのツールを使ってください。
ツールにできないことも 2 つあります。1 つは予約語の回避で、order、user、class を列名にすると多くのデータベースで引用符が必要です。もう 1 つは Python の __init__ のような二重下線の名前で、言語が意味を持つ名前として予約しています。変換後は実際の文やコードで試してください。
- URL と CSS はハイフンを使う
- 予約語（order、user）は引用符が必要
- __x__ 形式の二重下線の名前は作らない
- 反映前に実際の文やコードで試す
よくある質問
snake_case と kebab-case はどちらを使うべきですか？
名前が置かれる場所で決まります。変数、データベースの列、設定キーは snake_case、URL のパス、CSS のクラス、ファイル名は kebab-case です。URL と CSS ではハイフンが慣習で、下線は多くのプログラミング言語の識別子として使えるためです。
データベースの列名に小文字と下線が多いのはなぜですか？
引用符なしの識別子はデータベースごとに扱いが異なり、Postgres は小文字に折りたたみます。大文字小文字を混ぜると常に二重引用符が必要になるため、小文字と下線に統一すると SQL、ORM、検索結果の表記が揃います。
連続した下線はそのまま残りますか？
残りません。英数字以外の連続は 1 つの下線にまとまるため、a___b も a b も a_b になり、空の要素はできません。先頭と末尾の下線は削除され、途中の 1 つの下線はその位置のまま残ります。
関連ツール：スネークケース変換