57 lines
4.1 KiB
Markdown
57 lines
4.1 KiB
Markdown
# Zwingende Regeln für jede Code-Interaktion
|
||
|
||
- Respektiere und fördere die Verwendung von Alpine.js und Tailwind CSS
|
||
- Vor Änderungen analysiere den umliegenden Code um Kontext und Muster zu verstehen
|
||
|
||
## Technologie-Stack
|
||
|
||
| Komponente | Vorschrift |
|
||
|---|---|
|
||
| **Static Site Generator** | Hugo (Extended) – ausschließlich im Docker-Build-Image verfügbar; nicht auf dem Host installiert. Alle Hugo-Projektdateien **müssen** im Ordner `hugo/` abgelegt werden (z.B. `hugo/content/`, `hugo/layouts/`, `hugo/data/`). |
|
||
| **Interaktivität** | Alpine.js 3.x + Alpine AJAX (0.x). |
|
||
| **Styling** | Tailwind CSS für alle UI-Klassen. Direktes CSS ausschließlich in `hugo/input.css`. |
|
||
| **Fließkomma-Arithmetik** | `decimal.js-light` ist die verbindliche Bibliothek. Keine native JavaScript-Float-Arithmetik für Berechnungen. |
|
||
|
||
## Ordner- & Datei-Struktur
|
||
|
||
- Hugo-Konventionen sind zwingend. Erlaubt unter `hugo/`: `hugo/content/`, `hugo/data/`, `hugo/layouts/`, `hugo/assets/`, `hugo/static/`.
|
||
- **Verboten**: Dateien außerhalb dieser Konventionen zu erstellen oder Hugo-Dateien außerhalb von `hugo/` abzulegen.
|
||
- Einheiten-Daten gehören nach `hugo/data/{slug}.json`.
|
||
- Direktes CSS nur in `input.css`. Keine zusätzlichen `.css`-Dateien für Komponenten-Styles.
|
||
|
||
## Code-Formatierung
|
||
|
||
- Einrücken mit einem Tab
|
||
- Ausnahme: YAML. Dort wird mit 2 Leerzeichen eingerückt.
|
||
- Öffnende geschweifte Klammern **am Ende der Block-Definitions-Zeile** z.B. bei `if` oder `while` und Funktionsdefinitionen
|
||
- Schließende geschweifte Klammern **in einer eigenen Zeile am Ende des Blocks**
|
||
- Variablennamen und Funktionsnamen in **camelCase**
|
||
- Maximale Zeilenlänge: **80 Zeichen**; danach manueller oder automatischer Umbruch.
|
||
- **Einfache Anführungszeichen** `'` in JavaScript und Go; **doppelte Anführungszeichen** `"` in HTML-Attributen, JSON und YAML.
|
||
- **Keine trailing spaces** am Zeilenende.
|
||
- Jede Datei endet mit **genau einer Leerzeile** (POSIX-Konvention), aber keinem weiteren Whitespace in dieser Leerzeile.
|
||
- **Keine mehrfachen Leerzeilen** hintereinander (maximal eine Leerzeile zur Trennung von Blöcken).
|
||
- Kein Leerzeichen vor Komma, Semikolon oder Doppelpunkt; immer ein Leerzeichen danach.
|
||
- JavaScript: Keine `var`-Deklarationen; `const` als Standard, `let` nur bei tatsächlicher Re-Assignation.
|
||
- JavaScript: Asynchrone Operationen mit `async/await`; keine verschachtelten `.then()`-Ketten (Callback Hell).
|
||
- JavaScript: Keine verschachtelten ternären Operatoren.
|
||
- JavaScript: Arrow-Funktionen mit implizitem Return nur bei Einzeilern; mehrzeilige Arrow-Funktionen benötigen geschweifte Klammern und explizites `return`.
|
||
- Hugo Templates / Go: Keine verschachtelten Template-Logiken über **3 Ebenen** hinaus (z. B. `{{ if }}` in `{{ range }}` in `{{ if }}`); komplexere Logik muss in ein Partial ausgelagert werden.
|
||
|
||
## Verbotene Techniken & Anti-Patterns
|
||
|
||
- **Keine Änderungen im `app` Ordner** Der Ordner ist die Vorlage für die Migration und ist für Änderungen tabu.
|
||
- **Keine leeren `catch`-Blöcke.** Ein leerer `catch` muss mit einem erklärenden Kommentar versehen sein.
|
||
- **Keine überlangen Funktionen.** > 40 Zeilen signalisieren, dass eine Funktion aufgeteilt werden sollte.
|
||
- **Keine tiefen Verschachtelungen.** > 3 Einrückungsebenen (z. B. `if`-in-`if`-in-`if`) sind zu refactoren.
|
||
- **Keine magischen Zahlen oder String-Literale.** Werte mit semantischer Bedeutung müssen als benannte Konstanten definiert werden.
|
||
- **Keine ungenutzten Imports, Variablen oder Funktionen.** Sie müssen entfernt werden.
|
||
- **Keine `console.log`, `alert` oder `debugger` im Committeten Code.**
|
||
- **Keine doppelten Negationen.** Verwende explizite Boolean-Casts statt `!!`.
|
||
- **Keine globalen Variablen.** Daten müssen im jeweiligen Scope oder per explizitem State-Management (z. B. Alpine `x-data`) gehalten werden.
|
||
|
||
## Automatisierte Tests
|
||
|
||
- Vor Abschluss eines Features oder einer Änderung **muss** der Docker-Build-Test erfolgreich durchlaufen: `./tests/test-docker-build.sh`
|
||
- Der Test prüft drei Ebenen: erfolgreicher `docker build`, existenz wichtiger Artefakte (`index.html`, `css/main.min.css`, `robots.txt`) und ein HTTP-Smoke-Test gegen den laufenden Container.
|