テキスト・正規表現
名前の表記をそろえたい。camelCaseとsnake_caseをどう使う？
使うツール
APIではuser_id、画面のコードではuserId、CSSではuser-id。同じものを指していても表記がばらばらだと、写し間違いや検索漏れの原因になります。命名規則変換は、名前の候補をまとめて比べるために使えます。ただし、名前の意味を理解してソースコードの参照先まで直す機能ではありません。短い入力で区切り方を確認し、採用する表記を決めてから、変更する場所を選びましょう。
三つの単語から、六つの候補を比べる
user account id命名規則変換に入力して実行すると、camelCaseのuserAccountId、PascalCaseのUserAccountId、snake_caseのuser_account_id、kebab-caseのuser-account-idなどを比較できます。まず三つの単語が同じ順で残っていることを確認します。どの表記が一番きれいかだけではなく、既存のコードや連携先が採用している規則へ合わせるのが目的です。新しい項目だけ別の流儀にしないようにします。
結果には大文字のUSER_ACCOUNT_IDや、小文字で単語を空白区切りにした形も含まれます。これらをそのままどの言語の変数名にも使えるとは限りません。たとえばハイフンや空白を含む名前は、使う言語や文脈によって別の意味になります。ツールが候補として表示することと、その場所で有効な識別子であることは別に確認してください。
HTTPやURLは、人とツールで区切りが違う
HTTPServer
HTTP Server二行を一度に変換するのではなく、HTTPServerとHTTP Serverを一つずつ試します。現行の分割規則は、小文字や数字の直後に来た大文字を単語境界として扱います。HTTPServerのように大文字が続く境界を、人と同じようにHTTPとServerへ分けるわけではありません。そのためcamelCaseではhttpserverとhttpServerのように候補が変わります。意図した単語を空白で明示した入力と比べるのが確実です。
チームによってURLをUrlへ変えるか、URLのまま残すかも違います。既存の命名規約に合わせて、略語を一語とみなすのか文字単位で扱うのかを決めておきます。ツールの出力を採用する前に、API、ID、URLなどよく出る略語を数件試し、例外を記録します。自動変換の規則を知らないまま大量の名前へ適用すると、同じつもりの項目が別の名前になる原因になります。
数字と日本語を、自動翻訳だと思わない
api v2 responseこの入力ならcamelCaseはapiV2Response、snake_caseはapi_v2_responseになります。v2を一つのまとまりとして残すのか、vと2に分けたいのかは入力する単語で決まります。連番や版番号をすべて別の単語へ分解してくれる機能ではありません。最初が数字の名前も、変換結果が出るだけでプログラミング言語上有効になるわけではないため、採用先の識別子規則を確認します。
日本語などの文字を含めても、英語の意味へ翻訳したりローマ字へ直したりする処理は行いません。『顧客番号』をcustomerIdへ変えたいなら、customerとidという単語の選択は人が行います。その後で表記の候補を比べます。意味の翻訳と表記の変換を一度に済ませようとすると、同じ日本語へ違う英単語を割り当ててしまい、命名の一貫性がかえって下がることがあります。
別の名前が、同じ候補へ集まることがある
user-id、user_id、user idを一つずつ試すと、同じcamelCase候補へまとまります。これが表記ゆれの整理として便利な場合もあれば、元は別々の項目だったものを同じ名前へ潰す場合もあります。変換の前後で対応表を作り、変換後の名前が重複していないかを確認してください。出力だけを残して元の名前を捨てると、どの項目だったかを戻せなくなる可能性があります。
大文字小文字だけが違う名前も、ファイルシステム、DB、APIによって同一視されるかが異なります。名前の候補が違って見えるから衝突しない、とは判断できません。実際に使う場所で名前が比較される規則を確認します。このツールは、予約語、既存変数、ファイル名、外部の登録済み項目を照会して衝突を避けるものではありません。
APIの項目名と、内部の変数名を分けて変更する
外部APIがuser_idを要求しているなら、内部の変数をuserIdへそろえても、送信するJSONのキーまで変えてよいとは限りません。境界で対応付ける処理が必要です。ソースコード全体の文字列置換では、ドキュメントやテスト、文字列リテラルまで変えてしまうことがあります。実際のリネームには開発環境の参照追跡を使い、送受信データの固定テストで契約が変わっていないかを確認します。
採用する規則が決まったら、普通の単語、略語、数字、既存の区切り文字を含む例を数件だけ並べて、チームの命名例にします。変換ツールを何度も使わないと判断できない規約より、典型例から予測できる規約の方が維持しやすくなります。目的は名前を機械的に変えることではなく、次の人が同じ概念を同じ名前で書ける状態を作ることです。