SSPS - プロジェクト構造の統一基準

定義

SSPS標準では、プロジェクト内のファイルおよびフォルダの構造と命名規則に関する要件を定めています。

構造とセマンティクス

プロジェクト内のすべてのフォルダおよびファイルにおいて、小文字とハイフンの使用が必須です。これにより一貫性が確保され、問題の発生を防ぎ、また、大文字小文字の区別が異なる場合がありエラーを引き起こす可能性のある、さまざまなオペレーティングシステムやバージョン管理システム（Git）間での競合を回避します。

kebab-caseを使用することで、1つのディレクトリ内にgetPrice.ts、Price.tsx、Name.test.tsといった混乱を招く名前が混在する事態を防ぎ、CuteIDKOKReaderのような複雑な名前も読みやすいcute-id-kok-reader.tsに変換され、大文字小文字を区別するファイルシステムによるバグから保護されます。

なぜ snake_case ではないのか？ snake_case は Shift キーの過剰な使用を必要とし、Web 上で読みづらい（例えば、ファイルがアンダーバー付きのリンクとして表示される場合、_ が行と混ざって見えにくくなる）上、Google はアンダーバーの使用を公式に推奨していない。

唯一許容される例外は、READMEやCONTRIBUTINGなど、リポジトリのルートにあるシステムファイルです。これらは、ドキュメント作成の一般的な標準に従って大文字で表記されるためです。

ファイル名は、フォルダ構造がすでに提供している情報を重複して含んではいけません。

文脈は場所によって決まります。つまり、ファイルが features/auth にある場合、auth-login-form.tsx という命名は冗長であり、正しいのは login-form.tsx です。

HeaderUserMenuAvatar のような名前から widgets/header/ui/user-menu/avatar のような構造への移行により、ファイル名を簡潔かつ正確に保つことができます。

プロジェクトは、FSDに基づく明確な責任範囲を持つレイヤー構造で構成されます。

グローバルなグループ（entities、features、widgets）は常に複数形で命名され、その内部にある具体的なモジュール（スライス）は単数形で、内部セグメント（ui、model、api）は標準的な命名規則に従います。

これにより予測可能なアーキテクチャが構築され、カート変更のタスクは常に features/add-to-cart へ導かれ、そこでインターフェースとロジックが明確に分離されます。

統一された大文字小文字の規則（kebab-case）を使用することで、プロジェクトの統一感が生まれ、状況把握や課題解決が迅速に行えるようになります。