Swift Style

Swift Style Guide

Code style conventions for clean, readable Swift code.

Core Principles

Clarity > Brevity > Consistency

Code should compile without warnings.

Naming

• UpperCamelCase — Types, protocols
• lowerCamelCase — Everything else
• Clarity at call site
• No abbreviations except universal (URL, ID)

// Preferredlet maximumWidgetCount = 100func fetchUser(byID id: String) -> User

Golden Path

Left-hand margin is the happy path. Don't nest if statements.

// Preferredfunc process(value: Int?) throws -> Result {    guard let value = value else {        throw ProcessError.nilValue    }    guard value > 0 else {        throw ProcessError.invalidValue    }    return compute(value)}

Code Organization

Use extensions and MARK comments:

class MyViewController: UIViewController {    // Core implementation}
// MARK: - UITableViewDataSourceextension MyViewController: UITableViewDataSource { }

Spacing

• Braces open on same line, close on new line
• One blank line between methods
• Colon: no space before, one space after

Self

Avoid self unless required by compiler.

// Preferredfunc configure() {    backgroundColor = .systemBackground}

Computed Properties

Omit get for read-only:

var diameter: Double {    radius * 2}

Closures

Trailing closure only for single closure parameter.

Type Inference

Let compiler infer when clear. For empty collections, use type annotation:

var names: [String] = []

Syntactic Sugar

// Preferredvar items: [String]var cache: [String: Int]var name: String?

Access Control

• private over fileprivate
• Don't add internal (it's the default)
• Access control as leading specifier

Memory Management

resource.request().onComplete { [weak self] response in    guard let self else { return }    self.updateModel(response)}

Comments

• Explain why, not what
• Use // or ///, avoid /* */
• Keep up-to-date or delete

Constants

Use case-less enum for namespacing:

enum Math {    static let pi = 3.14159}

Common Mistakes

1. Abbreviations beyond URL, ID, UUID — Abbreviations like cfg, mgr, ctx, desc hurt readability. Spell them out: configuration, manager, context, description. The three exceptions are URL, ID, UUID.

2. Nested guard/if statements — Deep nesting makes code hard to follow. Use early returns and guards to keep the happy path left-aligned.

3. Inconsistent self usage — Either always omit self (preferred) or always use it. Mixing makes code scanning harder and confuses capture semantics.

4. Overly generic type names — Manager, Handler, Helper, Coordinator are too vague. Names should explain responsibility: PaymentProcessor, EventDispatcher, ImageCache, NavigationCoordinator.

5. Implied access control — Don't skip access control. Explicit private, public helps future maintainers understand module boundaries. internal is default, so omit it.