Sauberer Swift-Code: So schreiben Sie, dass Ihre Kollegen Sie nicht verfluchen

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Wie man sauberen Swift-Code schreibt: Ein Leitfaden für alle, die sich und ihre Kollegen respektieren

\n\n

Jeder Entwickler hat schon einmal ein Projekt geöffnet, das vor einem halben Jahr geschrieben wurde, und konnte nicht verstehen, was dort passiert. Oder erhielt beim Code-Review den Kommentar: „Das hätte man einfacher schreiben können.“ Kommt Ihnen das bekannt vor? Wenn ja, ist dieser Artikel für Sie.

\n\n

Sauberer Swift-Code ist nicht nur eine Marotte von Perfektionisten. Es ist ein Werkzeug, das Stunden des Debuggens und Nerven spart. Wenn Sie ordentlich schreiben, beschleunigen Sie nicht nur Ihre eigene Arbeit, sondern machen das Projekt auch für das Team transparent. Lassen Sie uns besprechen, wie Sie Ihren Swift-Code in ein Kunstwerk verwandeln.

\n\n

Regel Nr. 1: Namensgebung ist das A und O

\n\n

Die häufigste Sünde ist es, eine Variable x oder temp zu nennen. Dann kommt ein anderer Entwickler und rätselt: „Was ist x? Eine Koordinate? Eine Anzahl?“

\n\n

In Swift ist es üblich, Namen zu vergeben, die sich wie Sätze lesen. Das ist nicht nur schön – es hilft sofort zu verstehen, was der Code tut.

\n\n
// Schlecht\nlet a = 5.0\nvar b = "John"\n\n// Gut\nlet discountRate = 5.0\nvar userName = "John"
\n\n

Für Funktionen und Methoden gilt dieselbe Regel. Der Name sollte die Frage beantworten: „Was macht diese Methode?“ Verwenden Sie Verben im Imperativ:

\n\n
// Schlecht\nfunc data() -> [String] { ... }\n\n// Gut\nfunc fetchUsers() -> [String] { ... }
\n\n

Und wenn eine Funktion einen booleschen Wert zurückgibt, beginnen Sie den Namen mit is, has oder contains:

\n\n
func isUserLoggedIn() -> Bool\nfunc hasValidEmail() -> Bool
\n\n

Regel Nr. 2: Optionals sind keine Feinde, sondern Werkzeuge

\n\n

Viele Anfänger haben Angst vor Optionals und versuchen, sie um jeden Preis loszuwerden. Sie schreiben überall if let oder, noch schlimmer, sie forcen-unwrappen. Aber sauberer Swift-Code ist Code, der sicher mit nil umgeht.

\n\n

Denken Sie daran: ! ist ein Hilferuf. Verwenden Sie es nur, wenn Sie absolut sicher sind, dass der Wert nicht nil ist (z. B. bei der Arbeit mit IBOutlet).

\n\n
// Gefährlicher Code\nlet name = optionalName!\n\n// Sichere Variante\nguard let name = optionalName else {\n    return\n}\nprint(name)
\n\n

Und für Optional-Verkettungen verwenden Sie ? und nil-coalescing:

\n\n
let userCity = user?.address?.city ?? "Unbekannt"
\n\n

Dieser Code stürzt nicht ab, selbst wenn user oder address nil sind. Und er liest sich wie ein normaler Satz: „Stadt des Benutzers oder 'Unbekannt'“.

\n\n

Regel Nr. 3: Strukturen statt Klassen (wo möglich)

\n\n

In Swift gibt es sowohl Klassen als auch Strukturen. Aber viele verwenden aus Gewohnheit überall Klassen. Zu Unrecht. Strukturen sind Value Types und in Multithread-Code sicherer. Außerdem werden sie kopiert, nicht referenziert, was das Risiko von Seiteneffekten verringert.

\n\n

Verwenden Sie eine Struktur, wenn:

\n
    \n
  • Daten ohne komplexe Logik gespeichert werden müssen
  • \n
  • Keine Vererbung erforderlich ist
  • \n
  • Das Objekt nach der Erstellung nicht veränderbar sein soll
  • \n
\n\n
// Besser eine Struktur\nstruct User {\n    let id: Int\n    var name: String\n}\n\n// Klasse – nur wenn Vererbung oder Reference Semantics benötigt wird\nclass ViewController: UIViewController { ... }
\n\n

Übrigens empfiehlt Apple die Verwendung von Strukturen für Datenmodelle. Dies ist eines der Hauptprinzipien von sauberem Swift-Code.

\n\n

Regel Nr. 4: Protokolle sind Ihre besten Freunde

\n\n

Protokolle in Swift sind nicht nur Schnittstellen. Sie sind eine Möglichkeit, Code flexibel und testbar zu machen. Anstatt sich an eine bestimmte Klasse zu binden, arbeiten Sie über ein Protokoll.

\n\n
protocol NetworkServiceProtocol {\n    func fetchData(completion: @escaping (Result<Data, Error>) -> Void)\n}\n\nclass APIService: NetworkServiceProtocol { ... }\nclass MockService: NetworkServiceProtocol { ... }
\n\n

Jetzt können Sie den echten Dienst einfach durch einen Mock für Tests ersetzen. Und Sie müssen den Code nicht ändern, um

Blogs

Buchempfehlungen