テキストおよび日常ツール · テキスト ツールキット
キャメルケース、スネークケース、ケバブケース、およびパスカルケース: それぞれが使用される場所
· 背景
大文字と小文字の変換 識別子 開発者ワークフロー
命名規則のツアー - 命名規則がどこから来たのか、どの言語とエコシステムがどれを期待しているのか、そしてなぜファイル名、URL、データベース列、JSON キーがそれぞれ異なる方向に引っ張られるのか。
1 つのことに 5 つの名前 - userProfileId、user_profile_id、user-profile-id、UserProfileId、および USER_PROFILE_ID
「ユーザー プロファイル ID」という語句は、単語を変更せずに `userProfileId`、`UserProfileId`、`user_profile_id`、または `user-profile-id` になる可能性があります。目に見える違いは、境界が現れる場所と、最初の単語が大文字で始まるかどうかです。 ToolAcre は同じ入力からこれら 4 つのフォームを直接生成するため、構造的な違いを簡単に比較できます。
すべて大文字の `USER_PROFILE_ID` も便利なプロジェクト規約ですが、これは大文字小文字コンバーター ソース内の個別の組み合わせオプションではありません。ツールキットは、スネークケースと大文字の変換を個別に公開します。コードベースで大文字の定数が使用されている場合は、ケース メニューが両方の手順を一度に実行すると主張するのではなく、スネーク ケースに変換してから大文字にします。
Text Toolkit によって示される 4 つの変換と、個別に組み立てられた大文字の定数形式
`camelCase` は小文字の単語で始まり、後続のすべての単語の先頭が大文字になります。 `PascalCase` は、最初の単語も大文字にしながら、同じ結合単語の形状を適用します。 ToolAcre では、両方の変換が同じ単語スプリッターで始まるため、出力が組み立てられる前に句読点と既存の大文字と小文字の境界が解釈されます。
多くのチームは 2 つのフォームに異なる種類の名前を割り当てていますが、リポジトリは共通言語ルールやその分割の歴史を確立していません。ローカルのスタイル ガイド、リンター、フレームワーク API、または近くのコードを認証局として扱います。コンバーターはスペルの形状を変更します。名前がクラス、関数、変数、またはコンポーネントを表すかどうかは決まりません。
キャメルケースとパスカルケースは最初の文字が異なります。彼らの言語履歴はリポジトリの証拠の外にあります
`snake_case` は、検出されたすべての単語を低くし、結果をアンダースコアで結合します。 `User Profile ID` の場合、ToolAcre は `user_profile_id` を返します。区切り文字は表示されたままになるため、大文字と小文字の区別が確実に保持されないシステムを名前が通過する場合に役立ちますが、その実際的な利点は、すべてのデータベース、言語、またはサービスがアンダースコアを期待していることを証明するものではありません。
宛先ですでに定義されている規則を使用します。 Python サービスには 1 つのポリシー、別の SQL スキーマ、および 3 番目のシリアル化されたペイロードが含まれる場合があります。 ToolAcre はそれらの契約を検査できません。その信頼性の高い約束はより限定的です。`toSnakeCase` は単語を検出し、それぞれを小文字にし、宛先がその結果を許可するか優先するかを決定せずに単語の間に `_` を挿入します。
snake_case 出力は直接サポートされています。エコシステムと SQL の期待は各プロジェクトによって異なります
`kebab-case` は同じ小文字の単語を使用しますが、それらをハイフンで結合して、`user-profile-id` を生成します。この形状は、設定されたルート セグメントやプロジェクト定義のファイル名など、ハイフンがデータとして受け入れられる場所では視覚的に明確です。パーサーはハイフンを 1 つの名前の一部ではなく演算子として読み取ることができるため、これは JavaScript 識別子ではありません。
アウトラインには CSS クラス、HTML 属性、コマンドライン フラグ、および URL スラッグがリストされていますが、テキスト ライブラリはこれらのコンシューマのルールを定義していません。変換する前にターゲットの構文を確認してください。 ToolAcre には、アクセントの折りたたみ、区切り記号の選択、トリミング、およびオプションの長さ処理を備えた別の `slugify` 関数もあるため、通常のケバブ変換は完全な URL スラッグ検証として表示されるべきではありません。
ケバブケース出力は直接サポートされています。有効な使用方法は周囲の構文によって異なります
境界は、表面的なものではなく、命名規則が機能する場所です。ブラウザ オブジェクトではあるスペルを使用できますが、API ペイロードまたはデータベース列では別のスペルが使用されます。変換をビュー、クエリ、ビジネス ロジックに分散させるのではなく、1 つのアダプターでそのマッピングを明示的にします。予測可能なエッジにより、各内部モデルの一貫性が維持され、不一致を見つけやすくなります。
識別子に見えるという理由だけで任意の値を変換することは避けてください。単語スプリッターは句読点を境界として扱い、小文字、大文字、数字の間の選択された遷移を認識します。これは名前には便利ですが、スペルが外部で固定されているキーを変更する可能性があります。受信インターフェイスが制御下でマッピングを文書化しない限り、コントラクト キーを正確に保持します。
実用的な例 — すべての規則に従って 1 つの識別子を変換し、小規模プロジェクト内のどこにどれが属するかを決定する
`user profile ID` というフレーズを持つ小さなアプリケーションを考えてみましょう。 ToolAcre は、キャメル ケースの場合は `userProfileId`、パスカル ケースの場合は `UserProfileId`、スネーク ケースの場合は `user_profile_id`、ケバブ ケースの場合は `user-profile-id` を生成します。各出力には同じ 3 つの検出された単語が含まれ、大文字と挿入された区切り文字は選択された形状をエンコードします。
実際のプロジェクトでは、`userProfileId` を JavaScript オブジェクトに保持し、それを永続境界で `user_profile_id` に明示的にマップし、文法がハイフンを受け入れる場所として `user-profile-id` を予約します。正確な選択肢はそのプロジェクトに属します。重要な部分は、外観から繰り返し推測するのではなく、各境界を文書化し、マッピングをテストすることです。
これでカバーされないもの — ハンガリー語の表記法と識別子内の略語に関する議論
この比較では、略語の綴りは決定されません。実装では、検出された単語を再構築する前に小文字に変換するため、`HTTP` を含む入力は、Pascal または Camel 出力内で `Http` として表示される場合があります。チームが `Http`、`HTTP`、`Id`、または `ID` のいずれを好むかは、これらの一般的な変換以外の明示的な例外を必要とする命名ポリシーです。
また、表記の歴史、言語標準、またはすべての有効な識別子の文法もカバーしていません。これらの主張には、この記事で使用したツール ファイル以外のソースが必要です。 ToolAcre は決定論的なテキスト変換を示し、重要な制限の 1 つを文書化しています。それは、検出可能な境界を持たずに書かれた複合語は、人が意図した単語に常に分割できるわけではないということです。
略語ポリシーと表記履歴はコンバーターの証拠の外にあります
普遍的に正しいケースはありません。名前は、契約に従っており、そのレイヤーを管理している人々に認識可能なままである場合に役立ちます。すでに存在する規則から始めて、1 つのフォームを境界内に保持し、別のインターフェイスが必要とする場合にのみ変換します。一貫性は、すべてのエコシステムが 1 つのルールを共有しているかのように装うことなく、偶発的な差異を軽減します。
境界に別の形状が必要な場合は、テキスト ツールキットのケース コンバーターに識別子を貼り付け、1 つを適用する前に 4 つの出力を検査します。操作はブラウザーで実行され、マニフェストにはテキストがサーバーに送信されず、自動保存されないことが記載されています。結果を意図的なマッピングとして使用し、プロジェクトのテストとローカル スタイル チェックで最終的な選択を確認します。