プロジェクトとディレクトリの命名規則ガイド

ファイル名などの命名規則

代表的なパターン

命名規則	例	主な使われ方	メリット	デメリット
パスカルケース	SimpleMpmCpp	クラス名、型名（C++, Java, C#など）	コード内の識別子と一致させやすい	単語区切りが読みにくいことがある
ケバブケース	simple-mpm-cpp	リポジトリ名、URL、npmパッケージ名	最も読みやすい、URLフレンドリー	多くの言語で変数名やファイル名に使えない
スネークケース	simple_mpm_cpp	変数名、関数名、ファイル名（C, Pythonなど）	読みやすい	URLではハイフンの方が好まれる傾向がある

---

結論: 命名規則は「役割」と「階層」で使い分ける

命名規則に絶対の正解はないが、安全性・一貫性・効率性を高めるためのベストプラクティスは存在する。基本方針は「郷に入っては郷に従え」。つまり、言語やチームの慣習を尊重し、OSやツール間の互換性を最優先に考える。

---

1. プロジェクト名（リポジトリ名）の命名

推奨: ケバブケース（kabab-case）

例: my-awesome-app, simple-mpm-cpp

• 理由
  • URLフレンドリー: GitHubなどのURLとして最も見やすい
  • 互換性: 多くのパッケージマネージャ（npmなど）で推奨されている
  • 視認性: 単語区切りが明確でわかりやすい
  • 安全性: ファイル名としてOS間の互換性問題（大文字/小文字）を完全に回避できる
• 避けるべきパターン
  • Simple-MPM-Cpp のようなパスカルケースとハイフンの混合
    • 理由: 一貫性がなく、コード上の識別子（クラス名など）と乖離するため

---

2. ディレクトリの命名

2-1. プロジェクトをジャンル分けする「大分類ディレクトリ」

推奨：ケバブケース (kebab-case)
例： /projects/web-apps/, /projects/mobile-apps/

• 役割: 開発環境の「インフラ」層。OS、Git、各種ツールから参照される土台
• 最優先事項: 安全性と普遍性
• 理由
  • OS間の互換性: 大文字/小文字を区別するOS (Linux) としないOS (Windows, macOS) の間で起こる致命的な問題を未然に防ぐ
  • コマンドラインでの効率: Shiftキー不要で高速に入力できる
  • 予測可能性: 誰が見ても予測しやすく、スクリプトなどでの自動処理にも強い

2-2. 特定プロジェクト「内部」のディレクトリ

推奨：プロジェクトの言語やフレームワークの慣習に従う
例：

• Reactプロジェクト： MyProject/src/components/UserProfile/ (パスカルケース)
• C++プロジェクト： MyProject/src/utils/ (スネークケース)
• 役割: プロジェクト固有の「ローカルルール」が適用される領域
• 理由:
  • コードの命名規則とディレクトリ構造に一貫性を持たせることで、開発体験が向上する
  • フレームワークが自動生成するディレクトリ構造と合わせることで、混乱を避ける

---

3. 使い分けの思考プロセス：思想と現実のバランス

• パスカルケース (PascalCase)
  • 思想: 「クラス」や「概念的なグループ」を表すのに適している。静的で大きな枠組みを示す
  • 適用例: Competitions/, MyWebApp/
  • 注意点: OS間の互換性リスクがあるため、開発の「インフラ層」での使用は避けるべき。個人利用やプロジェクト内部など、影響範囲が限定的な場面で使う
• ケバブケース (kebab-case) / スネークケース (snake_case)
  • 思想: 「システムフォルダ」や「インスタンス（実例）」を表すのに適している。動的で具体的な項目を示す
  • 適用例: web-app/, competition_1, user_data
  • 利点: 非常に安全で、あらゆる環境で一貫した動作を保証する。迷ったらこれを選んでおけば間違いない