SSPS – Einheitlicher Standard für Projektstruktur

Definitionen

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

Struktur und Semantik

Die Verwendung von Kleinbuchstaben und Bindestrichen ist für alle Ordner und Dateien des Projekts obligatorisch. Dies sorgt für Einheitlichkeit, gewährleistet einen reibungslosen Ablauf und verhindert Konflikte in verschiedenen Betriebssystemen und Versionskontrollsystemen (Git), in denen die Groß-/Kleinschreibung unterschiedlich behandelt werden kann und zu Fehlern führen kann.

Die Verwendung von kebab-case verhindert Chaos wie getPrice.ts, Price.tsx und Name.test.ts in einem Verzeichnis; komplexe Namen wie CuteIDKOKReader werden in das lesbare cute-id-kok-reader.ts umgewandelt und schützt vor Fehlern durch Case Sensitive FS.

Warum nicht snake_case? Es erfordert übermäßigen Gebrauch der Shift-Taste, ist im Web schwer lesbar (wenn eine Datei beispielsweise als unterstrichener Link angezeigt wird, verschmilzt das _ mit der Zeile) und Google rät offiziell von der Verwendung von Unterstrichen ab.

Die einzige zulässige Ausnahme bilden Systemdateien im Stammverzeichnis des Repositorys, wie README oder CONTRIBUTING, da deren Großschreibung durch allgemein anerkannte Dokumentationsstandards vorgegeben ist.

Der Dateiname sollte keine Informationen wiederholen, die bereits durch die Ordnerstruktur vermittelt werden.

Der Kontext wird durch den Speicherort bestimmt; wenn sich die Datei also in features/auth befindet, ist die Benennung 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.

Das Projekt ist nach Schichten mit klaren Zuständigkeitsbereichen gemäß FSD aufgebaut.

Globale Gruppen (entities, features, widgets) werden immer im Plural benannt, konkrete Module (Slices) darin im Singular, interne Segmente (ui, model, api) bleiben standardmäßig.

Dies schafft eine vorhersehbare Architektur: Eine Änderung am Warenkorb führt immer zu features/add-to-cart, wo Schnittstelle und Logik klar voneinander getrennt sind.

Die Verwendung einer einheitlichen Schreibweise (kebab-case) sorgt für Einheitlichkeit in den Projekten, was dabei hilft, sich schneller zurechtzufinden und Aufgaben zu lösen.