Einleitung: Warum Ihr Code um Hilfe schreit (und wie MARK: ihn beruhigt)
\n\nStellen Sie sich vor: Sie öffnen eine Swift-Datei mit 500 Zeilen. Ihre Augen huschen über den Bildschirm, Sie suchen die Methode tableView(_:cellForRowAt:), aber ertrinken im Meer von func und var. Kommt Ihnen bekannt vor? Im Jahr 2025, wenn Projekte immer komplexer werden und die Entwicklungsgeschwindigkeit entscheidend ist, ist eine solche Situation ein direkter Weg zu Bugs und Zeitverlust.
Auf Stack Overflow hat die Frage "#pragma mark in Swift?" tausende Aufrufe erhalten. Und das aus gutem Grund. Entwickler, die von Objective-C gewechselt sind, suchten nach einem vertrauten Werkzeug, und Neulinge nach einer Möglichkeit, Ordnung in den Code zu bringen. Die Antwort ist einfach und elegant: In Swift gibt es kein #pragma mark, aber es gibt ein leistungsstärkeres Äquivalent – // MARK:.
In diesem Artikel erklären wir nicht nur, wie man // MARK: in Swift verwendet. Wir zeigen die Best Practices für 2025, die Ihren Code in ein Kunstwerk verwandeln, das sowohl für Sie in einem Jahr als auch für Ihre Kollegen verständlich ist. Machen Sie Xcode bereit – es wird interessant.
\n\nWas ist // MARK: in Swift und wozu braucht man es?
\n\nWenn Sie jemals mit Objective-C gearbeitet haben, erinnern Sie sich an #pragma mark. Dies ist eine Präprozessor-Direktive, die half, Methoden im Navigationsbereich von Xcode zu gruppieren. In Swift wurde sie abgeschafft, aber die Funktionalität wurde durch spezielle Kommentare beibehalten.
// MARK: ist ein Kommentar, den Xcode als Abschnittstrenner interpretiert. Es fügt im Navigationsbereich (Jump Bar) eine fette Überschrift und eine Trennlinie hinzu. Das sieht so aus:
\n\n// MARK: - Lifecycle\n\noverride func viewDidLoad() {\n super.viewDidLoad()\n}\n\n// MARK: - Table View Data Source\n\nfunc tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {\n return items.count\n}\n\n\nBeachten Sie den Bindestrich nach MARK: (// MARK: -). Er fügt eine horizontale Trennlinie hinzu. Ohne Bindestrich gibt es nur fetten Text. Verwenden Sie beide Varianten, je nachdem, wie stark Sie Blöcke visuell trennen möchten.
Schlüsselwörter für SEO: Verwendung von // MARK: in Swift, Code-Organisation Swift, Xcode-Navigation.
\n\nBest Practices für die Verwendung von // MARK: im Jahr 2025
\n\nEinfach überall // MARK: einzufügen, ist eine schlechte Idee. Das erzeugt nur Rauschen. Hier sind bewährte Techniken, die von Top-iOS-Entwicklern verwendet werden.
1. Gruppieren Sie nach Protokollen und Zuständigkeiten
\n\nDas häufigste Szenario ist die Implementierung mehrerer Protokolle in einer Klasse. Zwingen Sie Ihre Kollegen nicht zu raten, wo UITableViewDelegate endet und UITableViewDataSource beginnt.
final class ProfileViewController: UIViewController {\n\n // MARK: - Properties\n\n private let viewModel: ProfileViewModel\n private let tableView = UITableView()\n\n // MARK: - Lifecycle\n\n override func viewDidLoad() {\n super.viewDidLoad()\n setupUI()\n }\n\n // MARK: - UITableViewDataSource\n\n override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {\n return viewModel.sections.count\n }\n\n override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {\n // ...\n }\n\n // MARK: - UITableViewDelegate\n\n func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {\n viewModel.didSelectRow(at: indexPath)\n }\n\n // MARK: - Private Methods\n\n private func setupUI() {\n // ...\n }\n}\n\n\nDies ist der Goldstandard. Jeder Block ist für eine logische Einheit verantwortlich.
\n\n2. Verwenden Sie // MARK: - für logische Abschnitte innerhalb einer Klasse
\n\nAuch wenn Sie keine Protokolle implementieren, unterteilen Sie lange Klassen in Abschnitte: Public Methods, Private Methods, Helpers, Actions.