Swift-Code-Review: 7 Fehler, die Senior-Entwickler nerven

Swift-Code-Review: Wie Sie aufhören, Ihre Kollegen zu nerven und Code auf Senior-Niveau schreiben

Haben Sie jemals einen Pull Request gesendet und eine Stunde später 15 Kommentare vom Teamleiter erhalten? "Force Unwrap? Ernsthaft?", "Wo ist die Fehlerbehandlung?", "Dieser Flow-Controller hängt seit drei Tagen im Speicher." Kommt Ihnen bekannt vor? Willkommen in der Welt des Swift-Code-Reviews – ein Ort, an dem sich selbst erfahrene Entwickler manchmal wie Praktikanten fühlen.

In diesem Artikel habe ich die häufigsten Anmerkungen zusammengestellt, die Seniors bei Code-Reviews hinterlassen. Wir analysieren reale Code-Beispiele, Anti-Patterns und wie man sie behebt. Das ist keine langweilige Theorie – es ist die Kampferfahrung aus Hunderten von Reviews, die Ihnen hilft, Code zu schreiben, der nicht den Wunsch weckt, alles von Grund auf neu zu schreiben. Los geht's!

1. Force Unwrap – erste Liebe und größter Schmerz

Beginnen wir mit dem Banalsten, aber Ewigen. Force Unwrap (!) ist wie Autofahren ohne Sicherheitsgurt. Bequem, aber eine scharfe Bremsung und Sie landen in der Unfallchirurgie.

Schlechter Code (typischer Junior):

func getUserName() -> String {    let name: String? = UserDefaults.standard.string(forKey: "user_name")    return name!}

Was der Senior sagt: "Was, wenn in UserDefaults nichts steht? Crash. Immer. Füge guard let oder einen Standardwert hinzu."

Guter Code:

func getUserName() -> String {    guard let name = UserDefaults.standard.string(forKey: "user_name") else {        return "Gast"    }    return name}

Ausnahme: Force Unwrap ist nur in einem Fall zulässig – wenn Sie zu 146% sicher sind, dass der Wert existiert. Zum Beispiel bei der Arbeit mit IBOutlets, die garantiert initialisiert werden. Aber selbst hier wird der Senior empfehlen, private var label: UILabel! zu verwenden – das ist eine Konvention, kein Workaround.

2. Magische Zahlen und Strings: Code sollte kein Rätsel sein

Das Zweite, was bei einem Swift-Code-Review ins Auge fällt, sind magische Konstanten. "Warum genau 0.75? Ach, das ist der Animationskoeffizient... Welcher genau?" Wenn Sie Zahlen und Strings direkt in den Code schreiben, zwingen Sie Ihre Kollegen, Detektiv zu spielen.

Schlechter Code:

if user.age > 18 {    showAdultContent()}button.layer.cornerRadius = 12let url = "https://api.example.com/v1/users"

Was der Senior sagt: "18 ist eine magische Zahl. Ziehe sie in eine Konstante. Die URL in ein Enum. cornerRadius in eine Stilkonstante. Code sollte sich wie ein Buch lesen, nicht wie ein Code."

Guter Code:

private enum Constants {    static let adultAgeLimit = 18    static let defaultCornerRadius: CGFloat = 12    static let baseURL = "https://api.example.com/v1"}

enum APIEndpoint {    case users    var url: String {        switch self {        case .users: return Constants.baseURL + "/users"        }    }}

if user.age > Constants.adultAgeLimit {    showAdultContent()}

3. Memory Leaks: Wie man versehentlich die App aufhängt

Ein Swift-Code-Review kommt selten ohne die Diskussion von Retain Cycles aus. Seniors lieben dieses Thema, weil es zeigt, ob Sie verstehen, wie ARC funktioniert. Das beliebteste Anti-Pattern ist das Erfassen von self in einem Closure ohne weak-Referenz.

Schlechter Code:

class NetworkManager {    func fetchData(completion: @escaping (Data) -> Void) {        URLSession.shared.dataTask(with: url) { data, _, _ in            self.process(data) // self stark erfasst            completion(data)        }    }}

Was der Senior sagt: "Du hältst eine starke Referenz auf self innerhalb des Closures. Solange das Closure lebt, wird das Objekt nicht freigegeben. Füge [weak self] hinzu und prüfe auf nil. Oder verwende [unowned self], wenn du genau weißt, dass self das Closure überlebt."

Guter Code:

func fetchDa