TypeScript im Team: Code-Style, Konventionen und kein Chaos

Warum „es funktioniert“ ist nichts für ein Team?

Stellen Sie sich vor: Sie öffnen einen fremden PR und dort ist überall any, Variablen heißen a, b, c, und alles ist so formatiert, als hätte eine Katze, die über die Tastatur läuft, den Code geschrieben. Kommt Ihnen das bekannt vor? Alleine kann man mit so einem Code noch leben. Aber im Team führt das zu Konflikten, Bugs und schlaflosen Nächten beim Code-Review.

Heute sprechen wir darüber, wie man TypeScript im Team nicht nur zu einem Werkzeug, sondern zu einem soliden Fundament macht. Wir besprechen Code-Style und Konventionen, die Ihre Nerven schonen und die Entwicklung beschleunigen. Ohne Langeweile, mit lebendigen Beispielen.

1. Strenge Typisierung: Ihr erster Freund

Bei TypeScript geht es um Typen. Aber viele Teams nutzen es wie „TypeScript-lite“ und lassen überall any stehen, wo sie keine Lust zum Nachdenken haben. Das zerstört die ganze Magie. Die erste Konvention: any verbieten.

Schlecht:

function fetchData(url: string): any {    // ...}

Gut:

interface ApiResponse {    id: number;    name: string;    isActive: boolean;}

function fetchData(url: string): Promise<ApiResponse> {    // ...}

Wenn jeder Entwickler explizit beschreibt, was er zurückgibt und annimmt, wird der Code selbstdokumentierend. Sie müssen nicht mehr raten: „Ist dieses data ein String oder ein Objekt?“. Die Typen sprechen für sich.

2. ESLint + Prettier: Eine Einrichtung, über die nicht diskutiert wird

Wenn Ihr Team noch keinen einheitlichen Linter und Formatierer hat, halten Sie an und richten Sie diese sofort ein. ESLint fängt logische Fehler und Verstöße gegen den Code-Style ab, und Prettier sorgt für einheitlichen Code.

Basis-Konfiguration von ESLint für TypeScript:

{  "parser": "@typescript-eslint/parser",  "plugins": ["@typescript-eslint"],  "extends": [    "eslint:recommended",    "plugin:@typescript-eslint/recommended",    "prettier" // unbedingt am Ende  ],  "rules": {    "@typescript-eslint/no-explicit-any": "error",    "@typescript-eslint/explicit-function-return-type": "warn",    "no-console": "warn"  }}

Fügen Sie Prettier mit einfachen Regeln hinzu: Tabs statt Leerzeichen (oder umgekehrt, aber einheitlich), einfache Anführungszeichen, Semikolon am Ende. Und aktivieren Sie formatOnSave in der IDE. Das erspart endlose Diskussionen über Einrückungen.

3. Namensgebung: Sprechen Sie eine gemeinsame Sprache

Namenskonventionen sind wie Verkehrsregeln. Ohne sie herrscht Chaos. In TypeScript sind diese Konventionen üblich:

• camelCase für Variablen, Funktionen, Methoden: getUserData(), userName
• PascalCase für Klassen, Interfaces, Typen: UserProfile, ApiResponse
• UPPER_SNAKE_CASE für Konstanten, die zum Zeitpunkt der Kompilierung bekannt sind: MAX_RETRY_COUNT, DEFAULT_TIMEOUT
• Präfix I für Interfaces – umstritten, aber viele Teams verwenden es: IUser. Klären Sie das zu Beginn.

Beispiel für schlechtes Naming:

const data = { n: 'Alex', a: 30 }; // was sind n und a?

Gut:

const userProfile = { name: 'Alex', age: 30 };

4. Projektstruktur: Verstecken Sie nicht alles in einer Datei

Wenn ein Projekt wächst, ist das Fehlen einer Struktur der größte Feind. Legen Sie die Ordner vorher fest. Hier ist eine beliebte Variante für ein TypeScript-Projekt:

• src/ – Quellcode
• src/components/ – UI-Komponenten (falls React)
• src/utils/ – Hilfsfunktionen
• src/types/ – globale Typen und Interfaces
• src/services/ – API-Interaktion
• src/hooks/ – benutzerdefinierte Hooks (falls React)
\