Code-Review in Rust: Was prüfen und wie man Feedback in der Praxis gibt

Einleitung: Warum Code-Review in Rust nicht nur eine Formalität ist

Code-Review ist einer der Schlüsselprozesse in der Entwicklung jeder qualitativ hochwertigen Software. Aber wenn es um Rust geht, bekommt dieser Prozess eine besondere Bedeutung. Rust ist eine Sprache mit einem einzigartigen System von Ownership und Borrowing, das der Compiler bereits zur Kompilierzeit prüft. Doch selbst wenn der Code kompiliert, bedeutet das nicht, dass er gut, sicher und effizient geschrieben ist.

In diesem Artikel besprechen wir, worauf genau bei Code-Reviews von Rust-Projekten zu achten ist, wie man konstruktives Feedback gibt, um Kollegen nicht zu verletzen, und wie man typische Fehler vermeidet, die der Compiler nicht abfängt. Der Artikel richtet sich an Entwickler, die bereits mit den Grundlagen von Rust vertraut sind, aber ihre Review-Fähigkeiten vertiefen möchten.

1. Speichersicherheit und Ressourcenverwaltung

Rust garantiert Speichersicherheit ohne Garbage Collector. Das entbindet jedoch nicht von der Notwendigkeit zu prüfen, wie der Entwickler unsafe-Blöcke, rohe Zeiger und externe FFI-Aufrufe verwendet.

Was prüfen:

\n
• Verwendung von unsafe: Jeder unsafe-Block muss gerechtfertigt und mit einem Kommentar versehen sein, warum er sicher ist. Wenn es ohne unsafe geht, ist das besser.
\n
• Ressourcenlecks: Prüfen Sie, ob alle Box, Rc, Arc und andere intelligente Zeiger korrekt freigegeben werden. Zyklische Referenzen über Rc ohne Weak sind beispielsweise ein häufiges Problem.
\n
• Drop-Reihenfolge: Wenn eine Struktur Felder mit einer benutzerdefinierten Drop-Implementierung enthält, stellen Sie sicher, dass die Zerstörungsreihenfolge nicht zu Fehlern führt.
\n

// Beispiel für schlechten Code: unsafe ohne Kommentare\nunsafe {\n    let ptr = ...;\n    // Keine Erklärung, warum dies sicher ist\n    *ptr = 42;\n}\n\n// Guter Code: Kommentar und sichere Alternative\n// Verwende unsafe nur für den Aufruf einer C-Funktion, die die Gültigkeit des Zeigers garantiert\nunsafe {\n    // Der Zeiger wurde von der C-API erhalten, die seine Gültigkeit während der Lebensdauer des Aufrufs garantiert\n    some_c_function(ptr);\n}\n

2. Idiomatischer Code und Stil

Rust hat seine eigenen Redewendungen, die sich von C++ oder Python unterscheiden. Code-Reviews sollten prüfen, wie sehr der Code dem Geist der Sprache entspricht.

Was prüfen:

\n
• Verwendung von Option und Result: Vermeiden Sie unwrap() und expect() ohne triftigen Grund. Verwenden Sie in Produktionscode die Fehlerbehandlung mit match, dem ?-Operator oder unwrap_or_else.
\n
• Pattern Matching: Bevorzugen Sie if let und match anstelle von Ketten von is_some()/is_ok().
\n
• Verwendung von Traits: Prüfen Sie, ob Traits sinnvoll implementiert sind. Beispielsweise sollte die Implementierung von Display eine lesbare Ausgabe liefern, nicht nur Debug.
\n
• Benennung: In Rust ist es üblich, snake_case für Variablen und Funktionen zu verwenden, CamelCase für Typen und Traits. Konstanten verwenden SCREAMING_SNAKE_CASE.
\n

// Schlecht: übermäßige Verwendung von unwrap\nlet value = some_option.unwrap();\n\n// Gut: Fehlerbehandlung\nlet value = match some_option {\n    Some(v) => v,\n    None => return Err("Value not found".into()),\n};\n\n// Noch besser: mit dem ?-Operator\nlet value = some_option.ok_or("Value not found")?;\n

3. Leistung und Allokationen

Rust bietet eine low-level Kontrolle über den Speicher, aber das bedeutet nicht, dass der Code automatisch schnell ist. Beim Review ist es wichtig, potenzielle Engpässe zu prüfen.

Was prüfen:

\n
• Überflüssige Allokationen: Prüfen Sie, ob unnötig String oder Vec