よくある質問
トークナイザはどのように単語の境界を判定していますか？
ルールは 2 つです。第一に、明示的な区切り文字(`-`・`_`・`.`・`/`・空白)はトークンを終わらせます。第二に、ケースの遷移が境界を示します。小文字や数字に大文字が続くケース(`userId` → `user|Id`)、または大文字の連続のあとに「大文字 + 小文字」が来るケース(`HTTPRequest` → `HTTP|Request`)です。両方を合わせると一般的な識別子スタイルが網羅されます。非 ASCII 文字はケース遷移しないため、識別子内の日本語や韓国語は単一のトークンとして残ります。
どの言語でどのケースを選べばよいですか？
慣例はおおむね固まっています。**JavaScript / TypeScript**: 変数・関数は camelCase、型・コンポーネントは PascalCase、定数は UPPER_SNAKE。**Python**: 変数・関数は snake_case、クラスは PascalCase、定数は UPPER_SNAKE。**Rust**: 変数・関数は snake_case、型・トレイトは PascalCase、定数は UPPER_SNAKE。**Go**: エクスポートする名前は `MixedCaps`、しないものは `mixedCaps`(camelCase)、アンダースコアは使いません。**CSS / HTML 属性**: kebab-case。**SQL / PostgreSQL**: テーブル・列は snake_case。**シェルスクリプト**: ファイル名は小文字または kebab-case、環境変数は UPPER。
略語が小文字化されてしまいます(`URL` → `Url`)。維持できますか？
本ツールではできません。すべてのケースは結合前にトークンを小文字化します。略語の保持は「このトークンは略語か?」というトークン単位の判断が必要で、入力ではなくコンテキストに依存します。Go のスタイルガイドが `HTTPRequest` を要求する場合は、ソースコードでその形を手書きするか、エディタのコマンドを使ってください。Java / TypeScript のように `HttpRequest` が好まれる場合は、本ツールの出力がすでに一致しています。
`apiV2` のように数字を含む識別子はどうなりますか？
`apiV2` は `api`・`v2` にトークン化されます。小文字 `i` と大文字 `V` の遷移が境界になるためです。数字 `2` は `v` トークンに付いたまま残るので、`snake_case` の結果は `api_v_2` ではなく `api_v2` になります。数字を独立したトークンにしたい場合(`api_v_2`)は、貼り付け前に明示的な区切り文字を挿入してください(`apiV-2`)。
日本語・韓国語・中国語の文字も扱えますか？
CJK 文字にはケース遷移が存在しないため、1 つのトークンとしてそのまま通り抜けます。`사용자ID` は `사용자`・`id` にトークン化されます(韓国語部分が 1 トークン、ラテン略語はケース規則で切り離されます)。スクリプトが混在する識別子では実用上問題なく動きます。純粋な CJK 入力に対しては snake / kebab 以外のケースは結合文字が `_` か `-` かの違いだけで見た目はほとんど同じになります。
複数の識別子を一度に変換できますか？
本ツールは入力を 1 つの識別子として扱います。複数行を貼り付けると、改行が区切り文字として働き、1 つの巨大なトークン列になります。SQL テーブルの全列名を camelCase に揃えるような実バッチには、`awk` や sed コマンドにパイプするか、エディタのマルチカーソル選択を使ってください。ウェブツールは 1 識別子ずつ高速に処理するために作られています。
関連する概念
識別子のケーススタイルは、プログラミング言語が名前の中で使えないことが多いスペース無しで、単語の境界を表現する方法です。5 つの形式が主流です。**camelCase** は最初の単語を小文字にし、残りを大文字始まりにします — JavaScript、Java、C# のメソッドなど。**PascalCase** はすべての単語を大文字始まりにします — ほとんどの言語の型名、.NET のメソッド、React のコンポーネントなど。**snake_case** は小文字とアンダースコアで結合します — Python、Ruby、Rust、SQL の列など。**kebab-case** は同じことをハイフンで行います — CSS、URL、シェルコマンドなど。**CONSTANT_CASE**(または SCREAMING_SNAKE)はすべて大文字でアンダースコア結合します — グローバル定数、環境変数、プリプロセッサマクロなど。
選択はほぼ完全に文化的で、技術的なものではありません。言語は構文的に複数のスタイルを許容し、コミュニティのスタイルガイドに従います — Python の PEP 8、Effective Go、Rust API Guidelines、Airbnb JavaScript Style Guide など。周辺エコシステムに合うスタイルを選ぶことで、コードが grep しやすくなり、IDE の自動補完が効きやすくなり、コードレビューはロジックに集中できます。プロジェクト内でスタイルが混在することが実際の誤りで、スタイルの選択そのものよりも一貫させることのほうが重要です。
気付かないうちにチームをつまずかせるエッジケースが 2 つあります。**略語** はコミュニティで意見が分かれます。Java / TypeScript は `HttpRequest`、Go は `HTTPRequest`、Microsoft の .NET は長さによって両方使い分けます(`HtmlParser` だが `IO`)。どちらを採用しても、レビュアーが毎週ぶり返さないよう規則を明文化してください。**データベース列 ↔ アプリケーションプロパティ** のマッピングが第二のホットスポットです — PostgreSQL の `user_profile_image_url` は TypeScript モデルの `userProfileImageUrl` になり、決定論的なケース変換層が必要です。Prisma・SQLAlchemy・TypeORM のような ORM はこれをスキーマ定義に組み込みます。手で行う場面で本ツールが効きます。
