Naming Rules

3.1 ドメイン別クラス命名規則

• TTSのインターフェースは歴史的経緯から Interface というクラス名になっており、新規エンジンはこのクラスを継承する。
• コンポーネント名には Component サフィックスを付けるが、準大号コンポーネント（SynthesisManager など）はマネージャー内部の複数管理クラスであり Component サフィックスは付けない。

4. 動詞プレフィックスの推奨

• 取得系は get_ / fetch_ を使う（例: fetch_user_profile）。
• 設定系は set_ を使う（例: set_voice_config）。
• 追加系は add_、削除系は remove_ を使う。
• 判定系は is_ / has_ / can_ を使う。
• イベントハンドラーは on_ を使う（例: on_chat_message）。

5. 可読性ルール

• 名前は意味が明確なものにする（例: calculate_total は calc より明確）。
• 略語は避けるか、一般的に認知されたもののみ使う（例: URL は可、usr は不可）。
• プロジェクト全体で同じ規則を一貫して使う。
• コレクションを返すメソッドは複数形を推奨（例: get_users、get_items）。

6. 避けるべき命名

• 意味が広すぎる名前（data, info, manager2 など）。
• 型情報だけを示す名前（str_name, list_items など）。
• スコープ内で競合しやすい短すぎる名前（a, tmp, val）。
• 同一概念に複数表記を混在させる命名（例: user_id と userid の混在）。

7. リネーム時の運用

• 公開 API のリネームは後方互換性への影響を先に確認する。
• 参照更新は定義だけでなくテスト・設定キー・ドキュメントまで含めて一括で行う。
• 「意味変更を伴うリネーム」と「純粋な表記統一」はコミット/PR上で分離する。
• 一括置換を行う場合は同名の別文脈を誤更新していないか差分確認する。

8. テスト観点（最小セット）

• 公開APIリネーム時に既存呼び出しが破壊されていないこと。
• 一括置換後に同名異義のシンボル誤変更がないこと。
• テスト名/fixture名が命名規約（test_...）を満たしていること。
• 外部仕様名（APIキー/DBカラム）を不正に内部規約へ変換していないこと。
• 既存モジュール内の表記ゆれ（例: user_id/userid）が増えていないこと。

9. 修正時チェックリスト

1. クラス名は PascalCase になっているか。
2. メソッド名・変数名は snake_case になっているか。
3. 定数は大文字 + アンダースコア区切りになっているか。
4. ファイル名は小文字 + アンダースコア区切りになっているか。
5. テスト関数は test_ で始まっているか。
6. プライベートメンバーは _ で始まっているか。
7. グローバル変数を避けているか（必要時のみ g_ を使用しているか）。
8. 名前が意味を明確に表しているか。
9. 略語は適切か。
10. 同一概念が複数表記に分裂していないか。
11. 外部仕様優先ルール（API/DB）と矛盾していないか。
12. リネーム時に参照箇所（実装・テスト・設定・文書）を取りこぼしていないか。