Grundsätzlich nutzen wir Eslint um so viele dieser Guidelines wie möglich sicherzustellen. Leider ist nicht alles automatisierbar. Deshalb ist es wichtig, dass wir diese Guidelines kennen und leben.
Die Guidelines gelten insbesondere für TypeScript und JavaScript. Jedoch wäre es gut, wenn diese auch bei anderen Sprachen so weit wie möglich angewendet werden.
Wenn eine Guideline nicht umgesetzt werden kann oder aus bestimmten Gründen nicht umgesetzt wird, soll dies mit einem Code-Kommentar festgehalten werden.
Die wichtigste Funktion der Datei soll immer so weit oben wie möglich stehen. Gefolgt von der zweit wichtigsten, etc.
Wir wollen möglichst nicht mehr als ein einzelnes export-Statement pro Datei haben. Dies darf kein Default-Export sein. Es gibt einzelne Ausnahmen, wo mehrere export -Statements wünschenswert sind. Dies ist jedoch eher die Ausnahme.
Insbesondere Model-Dateien (Interfaces, Typen, Schemas, etc.) sollen IMMER in eigene Dateien, am besten in einem model Ordner oder sogar im model-Package erstellt werden. So können wir diese ohne Bedenken von Circular-Dependencies überall verwenden.
Ausnahme bei Zod-Schemas: Dort ist es durchaus sinnvoll, wenn der Typ direkt im Schema zusätzlich exportiert wird.
Um Git-Konflikte zu vermeiden, sollen Code-Linien immer möglichst unabhängig sein. Das bedeutet konkret:
Das meiste kann hier mit Prettier und Eslint sichergestellt werden.
Nesting soll immer möglichst vermieden werden. Dafür können zum Beispiel Early-Returns verwendet werden.
https://www.youtube.com/watch?v=CFRhGnuXG-4
Variablen, Properties, etc. sollen möglichst immer read-only sein. Das bedeutet konkret:
readonly Modifier möglichst überall setzten