SSPS – Einheitlicher Standard für die Projektstruktur

Der SSPS-Standard legt Anforderungen an die Struktur und Benennung von Dateien und Ordnern im Projekt fest.

Überall kebab-case

Die Verwendung von Kleinbuchstaben und Bindestrichen ist für alle Ordner und Dateien des Projekts obligatorisch. Dies ist eine bewusste Wahl der Schreibweise, die Konsistenz gewährleistet und Probleme verhindert. Dieser Ansatz verhindert Konflikte in verschiedenen Betriebssystemen und Versionskontrollsystemen (Git), in denen die Groß-/Kleinschreibung unterschiedlich behandelt werden kann, was zu Fehlern beim Zusammenführen von Zweigen oder beim Erstellen auf CI führt.

Die Verwendung von kebab-case löst die folgenden Probleme:

• Es verhindert Chaos wie getPrice.ts, Price.tsx und Name.test.ts in einem Verzeichnis.
• Komplizierte Namen wie CuteIDKOKReader werden in lesbare Namen wie cute-id-kok-reader.ts umgewandelt.
• Es schützt vor Case Sensitive FS-Fehlern.

Warum nicht snake_case:

• Erfordert übermäßigen Gebrauch der Umschalttaste.
• Ist im Web schlecht lesbar (wenn die Datei beispielsweise als unterstrichener Link angezeigt wird, verschmilzt das Unterstrichzeichen mit der Linie).
• Google rät offiziell davon ab, Unterstriche zu verwenden.

Die Pfade in den Importen sehen einheitlich aus und sind leicht lesbar. Die einzige zulässige Ausnahme sind Systemdateien im Stammverzeichnis des Repositorys, wie README oder CONTRIBUTING, da ihre Großschreibung durch allgemein anerkannte Dokumentationsstandards vorgegeben ist.

Kontext durch Verschachtelung

Der Dateiname sollte keine Informationen duplizieren, die bereits durch die Ordnerstruktur bereitgestellt werden. In SSPS wird der Kontext durch den Speicherort bestimmt, d. h. wenn sich die Datei in features/auth befindet, ist die Bezeichnung auth-login-form.tsx überflüssig. Richtig wäre login-form.tsx.

Der Übergang von Namen wie HeaderUserMenuAvatar zur Struktur widgets/header/ui/user-menu/avatar ermöglicht es, Dateinamen kurz und präzise zu halten.

Architektonische Prinzipien von FSD

Das Projekt ist in Schichten mit klaren Verantwortungsbereichen aufgebaut. Globale Gruppen (entities, features, widgets) werden immer im Plural benannt. Konkrete Module (Slices) innerhalb dieser Gruppen werden im Singular benannt. Interne Segmente (ui, model, api) bleiben standardmäßig.

Dies schafft eine vorhersehbare Architektur, wobei die Aufgabe, den Warenkorb zu ändern, immer zu features/add-to-cart führt, wo Schnittstelle und Logik klar voneinander getrennt sind. Die Verwendung einer einheitlichen Schreibweise (kebab-case) macht Projekte einheitlich, was eine schnellere Orientierung und Problemlösung ermöglicht.