Regel
Entfernen auskommentiert Code Blöcke

Auskommentierte Code erzeugt Rauschen, wird veraltet 
und gehört in Version Kontroll Geschichte, nicht der Codebasis.

Einleitung

Auskommentierter Code sammelt sich an, wenn Entwickelnde unsicher sind, ob sie alte Logik später noch benötigen. Jemand kommentiert eine Funktion „nur für den Fall“ aus, anstatt sie zu löschen, und sie bleibt für immer dort. Niemand weiß, ob dieser Code noch funktioniert, warum er deaktiviert wurde oder ob er sicher entfernt werden kann. Die Codebasis füllt sich mit Geistern vergangener Implementierungen, die vom Verständnis dessen ablenken, was tatsächlich in Produktion läuft.

Warum es wichtig ist

Code-Wartbarkeit: Auskommentierter Code zwingt Lesende, mental zu filtern, was real und was inaktiv ist. Während eines Code-Reviews lässt sich nicht erkennen, ob diese Blöcke temporäre Experimente, wichtige Rollback-Optionen oder vergessene Überbleibsel von vor Jahren sind. Dieses Rauschen erschwert es, die tatsächliche Logik zu verstehen, relevante Code-Abschnitte zu finden und Änderungen sinnvoll zu überprüfen.

Sicherheitsimplikationen: Auskommentierte Authentifizierungsprüfungen, Validierungslogik oder Sicherheitsfunktionen zeigen, dass diese Schutzmaßnahmen existierten, aber absichtlich deaktiviert wurden. Wenn der auskommentierte Code Anmeldeinformationen, API-Schlüssel oder interne URLs enthält, liefern Sie diese sensiblen Daten im Klartext aus. Angreifer, die Ihren Code überprüfen, sehen genau, welche Sicherheitsmaßnahmen Sie in Betracht gezogen und entfernt haben.

Versionskontroll-Verwirrung: Git-Diffe werden durch auskommentierte Blöcke überladen, die sich eigentlich nicht ändern. Wenn Sie nachvollziehen müssen, wann sich die Logik geändert hat oder warum ein Feature auf eine bestimmte Weise funktioniert, verschleiern auskommentierte Alternativen die wahre Historie. Die Suche in der Codebasis liefert Treffer in totem Code, was Zeit bei der Untersuchung von Pfaden verschwendet, die nicht ausgeführt werden.

Code-Beispiele

❌ Nicht konform:

async function createUser(userData) {
    // const hashedPassword = await bcrypt.hash(userData.password, 10);

    const user = await db.users.create({
        email: userData.email,
        password: userData.password,
        // password: hashedPassword,
        role: userData.role || 'user'
    });

    // await sendWelcomeEmail(user.email);
    // await notifyAdmins(user);

    // Old validation approach
    // if (!isValidEmail(user.email)) {
    //     throw new Error('Invalid email');
    // }

    return user;
}

Warum es falsch ist: Das auskommentierte Passwort-Hashing zeigt, dass Passwörter im Klartext gespeichert werden, eine kritische Sicherheitslücke. Niemand weiß, ob die Willkommens-E-Mail und die Admin-Benachrichtigung aktiviert werden sollen, und die alte Validierung deutet darauf hin, dass eine E-Mail-Validierung fehlen könnte.

✅ Konform:

async function createUser(userData) {
    if (!isValidEmail(userData.email)) {
        throw new Error('Invalid email');
    }

    const hashedPassword = await bcrypt.hash(userData.password, 10);

    const user = await db.users.create({
        email: userData.email,
        password: hashedPassword,
        role: userData.role || 'user'
    });

    await sendWelcomeEmail(user.email);
    await notifyAdmins(user);

    return user;
}

Warum das wichtig ist: Die Funktion ist klar und vollständig und zeigt genau, was in der Produktion ausgeführt wird. E-Mail-Validierung läuft zuerst, Passwörter werden korrekt gehasht, und alle Benachrichtigungen werden ohne Unklarheiten darüber, was aktiviert ist, gesendet.

Fazit

Löschen Sie Code, anstatt ihn auszukommentieren. Ihr Versionskontrollsystem bewahrt jede jemals geschriebene Zeile auf, zugänglich über git log und git blame wenn Sie es brauchen. Kommentierter Code im Repository erzeugt nur Rauschen, das die eigentliche Logik verschleiert und Ihre Codebasis schwerer navigierbar macht.